One of the nice things (there are several others!) about dynamic languages like Python is that the code feels much cleaner. It is not bloated with type declarations all over. This clean feel was also the goal of the language Boo, and even though it is a static language, Boo really gives you that dynamic feel.

The question is the of course: Is the C# getting more dynamic?

Well to be honest I do not think so. Having to declare a type at all (even if the declaration is “dynamic”) feels quite static, and the code bloats like static languages. Most of the time. I think it is wrong to think that C# is a more dynamic language due to the dynamic keyword, and I feel you are not using the right tools if you try to use C# as a dynamic language. If you want to write dynamic code, use a dynamic language.

But when we get the dynamic keyword, lets find things to use it for. When I am introduced to new features I am not that interested in all the fancy things you can do with it, I want real value. And I think I have found an example of real value in the dynamic keyword. I’ll give you an example, other than in com-interop, where the dynamic keyword will help you keep your code nice and clean, where otherwise you’d have to write a whole lot of ugly code.

The Quick Xml Reader

The funny thing is that I have already implemented a nice xmlreader in Boo (using the IQuackFoo-interface). When the dynamic keyword was introduced in C# 4 and you’ve got the IDynamicObject from the DLR, I figured I can do the exact same thing in C#. That’s just cool!

So what did I do? Here’s the comment from the Boo code file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

class XmlReader(IQuackFu):
"""
Represents an xmldocument using "dynamic typing". 
Can be used to retrieve single values from the xml-document.
There is no support for retrieving lists.
 
Language: 
 Element: Both nodes and leaves
 Node: an element containing sub-elements
 Leaf: An element that represents a value (in xml this is an attribute or a node with nodetype text)
 
use method names to retrieve nodes, and properties to retrieve leaves
example:
<myXml stat="ok">
	<user id="123" nsid="123">
	    <username>Tore</username>
	    <password>foo</password>
	</user>
</myXml>
 
myXml as duck = XmlReader(xmlString)
myXml //will fail since "myXml" is no leaf
myXml() // will return a new XmlReaderrepresenting the rsp-node with children
myXml().stat // will return "ok"
myXml().user().username // will return "Tore"
"""

How cool is that? This is dynamic, resolved at run time, and it can now be done in C# as well. The point with parsing xml is that you won’t catch errors in the xml structure at compile time anyway. So why not just do the code dynamic?

So, our Xml reader let’s you easily get values from an xml structure without having to declare all the types and without having to worry about all the details of the xml-parsing that normally is a bit complex and frankly, boring. In addition the code is much more readable than normal xml-parsing code.

Xml reading in C#

So, how do we do this in C#? Our XmlReader is a class where you can use any method name or property name on it, and it will still compile. For example, This will compile:

1
2

dynamic ourReader = new XmlReader(xmlString);
ourReader.WhateverMethodNameYouLike();

To do this, the XmlReader needs to inherit the IDynamicObject, and it has to implement the method GetMetaObject that returns a MetaObject.

Simplifying the MetaObject

To implement a MetaObject and do some useful stuff you actually have to understand how to build a Linq expression tree that describes the action to be taken. If people are going to use this, it should be as simple as possible. Building Linq expression trees is not as simple as possible IMHO. So, I’ll make a generic base class that hides the whole MetaObject with its Linq expression trees, and let you override some methods in your XmlReader class instead.

I will not go into details on how I have done this, but if you’re interested, you can look at the source (there’s a link at the end). The ‘magic’ is within the MetaBaseDynamicObject. Together with the BaseDynamicObject these can be reused for different tasks that needs on the fly interpreting of property and method calls.

All you have to do is to inherit the BaseDynamicObject, and override any of these methods:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public class BaseDynamicObject:IDynamicObject
{
    /// <summary>
    /// If a method on this object is called run time, this method will be called.
    /// </summary>
    /// <param name="action">Information on the method that has been called</param>
    /// <param name="args">parameters on the method call</param>
    /// <returns>The return value for the originally called method</returns>
    public virtual Object Call(CallAction action, object[] args)
 
    /// <summary>
    /// If a property is set on this object run time, this method will be called.
    /// </summary>
    /// <param name="action">Information on the property which value is attemted set</param>
    /// <param name="value">the value that the property is attemted set with</param>    
    public virtual void SetMember(SetMemberAction action, object value)
 
    /// <summary>
    /// If a property is called on this object run time, this method will be called.
    /// </summary>
    /// <param name="action">Information on the property which is being called</param>
    /// <returns>The return value for the property that has been called</returns>
    public virtual Object GetMember(GetMemberAction action) //, MetaObject[] args)
}

Implementing the XmlReader

So what we have to do here is to create a class (XmlReader), inherit the BaseDynamicObject, and override Call and GetMember. We will not bother with SetMember now, as we do not want to support updating the xml. This is what it looks like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

public class XmlReader:BaseDynamicObject
{
    private readonly XmlElement element;
 
    public XmlReader(string xmlText) {
        var doc = new XmlDocument();
        doc.LoadXml(xmlText);
        element = doc.DocumentElement;
    }
 
    public XmlReader(XmlElement xmlelement)
    {
        element = xmlelement;
    }
 
    public override object Call(CallAction action, object[] args)
    {
        var elements = element.SelectNodes(action.Name);
        if (elements.Count == 0) 
            throw new Exception("Element '" + action.Name + "' doesn't exist in xml");
        if (IsLeaf((XmlElement)elements[0]))
            throw new Exception("Element '" + action.Name + "' is a Leaf and cannot be fetched as a Node");
        return new XmlReader((XmlElement)elements[0]);
    }
 
    public override object GetMember(GetMemberAction action)
    {
        var elements = element.SelectNodes(action.Name);
        if (elements.Count > 0) {
            if (IsLeaf((XmlElement)elements[0]))
                return elements[0].InnerText;
            else
                throw new Exception("Element '"+action.Name+"' is not a Leaf and cannot be fetched one");
        }
 
        var attribute = element.GetAttributeNode(action.Name);
        if (attribute == null)
            throw new Exception("Element '"+action.Name+"' doesn't exist in xml");
        return attribute.Value;
    }
 
    private bool IsLeaf(XmlElement leafElement)
    {
        return leafElement.ChildNodes.Count == 1 &&
            leafElement.ChildNodes[0].NodeType == XmlNodeType.Text;
    }
}

This class now does all the xml-handling. So that means you can do stuff like this:

1
2
3
4
5
6
7
8
9
10
11
12

string xmlString = 
	"<?xml version=\"1.0\" encoding=\"utf-8\" ?>" +
	"<myXml stat=\"ok\">" +
		"<user id=\"321\" nsid=\"123\">" +
		    "<username>Tore</username>" +
		    "<password>foo</password>" +
		"</user>" +
	"</myXml>";
dynamic myXml = new XmlReader(xmlString);
Console.WriteLine(myXml.stat); // "ok"
Console.WriteLine(myXml.user().username); // "Tore"
Console.WriteLine(myXml.user().nsid); // "123"

This is a real declarative and easy way to handle xml, and since xml will only fail run time anyway, there is no argument that you lose compile time checking either.

I hope that has triggered you a bit on some exciting possibilities on using the dynamic type.

Here’s the source. Please remember you will need C# 4.0 to make this work.

Thanks to this and this blog for giving me information and ideas.

-Tore Vestues

One problem with Boo is that lack of tutorials and help to everyone that wants to start out with Boo. I have spent quite some time scanning the Boo source code, trying and failing, and forever searching the web for information, never finding anything. It’s been a long road for me to learn the language, and I do not think it should be this hard for everyone else.

So, I’ve spent some time writing some tutorials on Boo’s compiler extensibility. Hope they help!

• What makes Boo great
• Boo Getting Started
• Boo extensions explained
• Boo AstAttributes explained
• Boo AstMacros explained

Feel free to contact me with any questions, and also if there are other topics you want covered.

-Tore Vestues

Before you read on, these posts might be useful to read:

• Boo Getting Started
• Boo extensions explained
• Boo AstAttributes explained

To create a Macro, you simply have to create a class that inherits from AbstractAstMacro and overrides the Expand-method. In addition your class name must end with “Macro”.

Let’s demonstrate with my DevNull-macro:

1
2
3
4
5
6

import Boo.Lang.Compiler
import Boo.Lang.Compiler.Ast
 
class DevNullMacro(AbstractAstMacro):
	override def Expand(macro as MacroStatement):
		pass

How do you use it? In your code (in a different assembly than where DevNullMacro is situated) you can write something like this:

1
2
3

def DoTheMath(x as int) as int:
	devNull:
		x>0

Here you send in a “Block” to the macro (”X>0″). You can actually also send arguments:

1
2
3

def DoTheMath(x as int) as int:
	devNull x,10,"Hello":
		x>0

So, a Macro can take any number of arguments, and then it takes a block (which can be as big as you like).

Now why did I call this macro DevNull? I did it to demonstrate how the macros work. The point is if you choose to do nothing in the Expand method, nothing will happen. The compiler will actually remove the macro with its arguments and its Block. Meaning that since it is only our macro that handles the code inside the block sent into the macro we can send in whatever we’d like.

This code actually compiles:

1
2
3
4

def DoTheMath(x as int) as int:
	devNull x,10,"Hello":
		x>0
		I_can_write_whatever_here_actually

Ok, so when the compiler hits a macro statement in the compiling code, it finds the macro implementation (in this case the DevNullMacro), and sends it both the arguments and the code block. The compiler then removes all that code, and continues.

(I know this might seem a little confusing. When I started learning Boo it helped quite a lot to look at the compiled code using a tool like Reflector. You should try to write this code and look at it. It will clear up a few things, believe me.)

So what is the point then? The point is that within the macro, you can add code to the code structure. You can of course add whatever you like, but normally you add something based on the input to the macro.

To demonstrate something useful, I will show you how to implement Design By Contract. I have previously demonstrated it in several talks I’ve held, but then I have implemented it as AstAttributes like this:

1
2
3
4
5
6
7
8

class Account:	
	public Balance as int
 
	[Require(amount>=0)]
	[Ensure(Balance == originalBalance + amount)]
	def Deposit(amount as int):
		originalBalance = Balance
		Balance += amount

I will not go into details about this, but I’m pretty sure you will manage to do it yourself after reading my post about AstAttributes.

Now I want to implement Design By Contract as macros, in the same way it is implemented in Eiffel, the language that introduced it. I want to write my assertions like this:

1
2
3
4
5
6
7
8
9
10
11
12

class Account:
 
	public Balance as int
 
	def Deposit(amount as int):
		requires:
			amount>=0
		body:
			originalBalance = Balance
			Balance += amount
		ensures:
			Balance == originalBalance + amount

We have three macros here: requires, body, and ensures. I’m going to show you in detail how to implement the requires-part of the code, then I’ll add the source for both body and ensures as well. When we hit the requires macro in the code, we’re going to replace it with some actual code that forces those requirements. So, where we find this code in our Deposit-method,

1
2

requires:
	amount>=0

we want, at compile time, to put something like this to the output assembly:

1
2

if not (amount>=0):
	raise Exception("Some suitable error message")

To add code where the macro statement is situated, we simply return a Statement from our Expand-method. What we want to make is a Block (which is a derived type of Statement):

1
2
3

override def Expand(macro as MacroStatement) as Statement:
	blockToReturn = Block()
	return blockToReturn

Still nothing happens, since we’re just returning an empty Block. We have to fill the return block with something. So for each assertion (which turns out as Statements) in our code, we want to assert it. Let’s loop all our statements:

1
2
3
4
5
6
7
8
9

override def Expand(macro as MacroStatement) as Statement:
	blockToReturn = Block()
 
	for statement in macro.Block.Statements:
		expression as BinaryExpression = TryMakeBinaryExpression(statement)
		blockToReturn.Add(
			CreateAssertblockFromBinaryExpression(expression))
 
	return blockToReturn

In addition to the looping, which is pretty straight forward, we’re doing two new things here. We’re trying to turn every statement into a BinaryExpression, and we’re creating blocks for each BinaryExpression.

Let’s look at our TryMakeBinaryExpression first. The point is that if we want to assert something, we have to make sure they resolve to either true or false. First we need all the Statements to be ExpressionStatements. If you for instance had written an if-statement in you macro like this:

1
2
3

requires:
	if 1==1:
		do_something

This will not be an ExpressionStatement, it is an IfStatement (you should look into the Boo class-hierarchy, use Visual studio or Reflector).

So, when we have assured us it is all ExpressionStatements we have to deal with, we also want to ensure they are all BinaryExpressions. They all have to resolve into either true or false. Both of these checks are run here:

1
2
3
4
5
6
7
8
9
10

def TryMakeBinaryExpression(statement as Statement) as BinaryExpression:
	expression = statement as ExpressionStatement 
	if expression is null:
		RaiseNotBinaryException(statement.ToString())
 
	binaryexpression = expression.Expression as BinaryExpression 
	if binaryexpression is null:
		RaiseNotBinaryException(expression.Expression.ToString())
 
	return binaryexpression

Ok, now we either have a BinaryExpression or it has already failed. Let’s make it into a block:

1
2
3
4
5
6
7

def CreateAssertblockFromBinaryExpression(expression as BinaryExpression) as Block:
	exceptionText = "Voilated precondition: " + expression.ToString()
	return [|
			block:
				if not $(expression):
					raise Exception($exceptionText)
		|].Block

Here we’re using quasiquotations again. It’s understandable and easy to both read and write.

And that’s the complete macro. So now for every BinaryExpression written, the macro will assert its correctness. Here’s the complete code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

import System
import Boo.Lang.Compiler
import Boo.Lang.Compiler.Ast
 
class RequiresMacro(AbstractAstMacro):
 
	override def Expand(macro as MacroStatement) as Statement:
		blockToReturn = Block()
		for statement in macro.Block.Statements:
			expression as BinaryExpression = TryMakeBinaryExpression(statement)
			blockToReturn.Add(
				CreateAssertblockFromBinaryExpression(expression))
		return blockToReturn
 
	def CreateAssertblockFromBinaryExpression(expression as BinaryExpression) as Block:
		exceptionText = "Voilated precondition: " + expression.ToString()
		return [|
				block:
					if not $(expression):
						raise Exception($exceptionText)
			|].Block
 
	def TryMakeBinaryExpression(statement as Statement) as BinaryExpression:
		expression = statement as ExpressionStatement 
		if expression is null:
			RaiseNotBinaryException(statement.ToString())
 
		binaryexpression = expression.Expression as BinaryExpression 
		if binaryexpression is null:
			RaiseNotBinaryException(expression.Expression.ToString())
 
		return binaryexpression
 
	def RaiseNotBinaryException(typeInfo as String):
		raise Exception("Not a binary expression: " + typeInfo)

The other two macros, BodyMacro and EnsuresMacro are listed here:

1
2
3
4
5
6
7
8

import System
import Boo.Lang.Compiler
import Boo.Lang.Compiler.Ast
 
class BodyMacro(AbstractAstMacro):
 
	override def Expand(macro as MacroStatement) as Statement:
		return macro.Block

Here we only need to return the actual code written within the macro.

And here’s the EnsuresMacro:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

import System
import Boo.Lang.Compiler
import Boo.Lang.Compiler.Ast
 
class EnsuresMacro(AbstractAstMacro):
 
	override def Expand(macro as MacroStatement):
		ancestor as Method = macro.GetAncestor(NodeType.Method)
 
		oldBody as Block = ancestor.Body
		ensuresBody as Block = RequiresMacro().Expand(macro)
		newBody = [|
			block:
				try:
					$oldBody
				ensure:
					$ensuresBody
		|].Block
 
		ancestor.Body = newBody

Here we take all the code in the method containing the macro, and surrounds it with a try-clause to ensure that we always run the ensures-part of the code. Notice also that we’re using the RequireMacro, since it creates the assert-block exactly the way we want it.

A helping hand:
When you explore this, I actually advice you to write some of your macro code in C#, as it gives you a lot more intellisense-help, then when you have found out what you want, write them back in Boo, as it is often much more readable, especially with the nice quasiquotation which you do not have in C#.

Hope it helps!

- Tore Vestues

Before you read on, these posts might be useful to read:

• Boo Getting Started
• Boo extensions explained

To implement an AstAttribute you have to create a class that inherits the AbstractAstAttribute-class and implements the Apply-method. The class name must be postfixed with “Attribute”, the syntax is then “‘YourAttributeName’Attribute”. Like this:

1
2
3
4
5
6

import Boo.Lang.Compiler
import Boo.Lang.Compiler.Ast
 
class DemoAttribute(AbstractAstAttribute):
	def Apply(type as Node):
		pass

You have now created an AstAttribute named Demo, and you can use it (from another assembly) like this:

1
2
3
4

[Demo]
class MyTestClass:
	def constructor():
		pass

For the moment our attribute does absolutely nothing. To make it do something we have to do some work in the Apply-method we implemented. The method takes a Node as an argument. A Node can be just about any type, since alot of classes inherit the Node-class. Here the Node is the actual “thing” that you tagged the Attribute with. In our example the Node will be a definition of the MyTestClass. Say you tag a Method you will get the method definition (including all its content) passed into the Apply method. We will examine the possibilities this gives us, but let us first take a look at what sub types the Node-class has, that are relevant for us.

The picture shows the relevant subtypes. In other words these subtypes show where you can use your attribute, meaning you can tag classes, method parameters, methods, constructors, fields and properties with an AstAttribute that you create.

To experiment with this, I’ve made a little solution for you that you, it will print just about any information that is available at compile-time. (I’ve added it at the bottom)

NotifyPropertyChanged

I want to demonstrate an AstAttribute that I’ve been using in quite a few of the presentations I’ve held on Boo, and that I have also mentioned in this blog earlier (What makes boo great): the NotifyPropertyChanged-attribute. I wrote this attribute about half a year ago, and it really blew my mind on all the possibilities Boo offers.

First let’s look at how we implement the INotifyPropertyChanged in C#, just to remind us of what parts we want to auto generate.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

public class Customer: INotifyPropertyChanged
{
    private string firstName;
    private string lastName;
 
    public string FirstName
    {
        get
        {
            return firstName;
        }
        set
        {
            firstName = value;
            NotifyPropertyChanged("FirstName");
        }
    }
    public string LastName
    {
        get
        {
            return lastName;
        }
        set
        {
            lastName = value;
            NotifyPropertyChanged("LastName");
        }
    }
 
    public event PropertyChangedEventHandler PropertyChanged;
 
    private void NotifyPropertyChanged(String info)
    {
        if (PropertyChanged != null)
        {
            PropertyChanged(this, new PropertyChangedEventArgs(info));
        }
    }
}

That code is as ugly as always. We basically want to write it like this:

1
2
3
4
5
6

[NotifyPropertyChanged]
class BooCustomer:
	[Property(LastName)]
	lastName as String
	[Property(FirstName)]
	firstName as String

Ok, the first thing we have to do is make sure the attribute is used on a class and not somewhere else. Let’s do it like this:

1
2
3
4
5
6
7
8
9

def Apply(target as Node):
	classDef = GetClassDefinition(target)
 
 
def GetClassDefinition(target as Node) as ClassDefinition:
	classDef = target as ClassDefinition
	if classDef is null:
		raise Exception("The NotifyPropertyChangedAttribute can only be used on classes")		
	return classDef

We’re casting the Node to a ClassDefinition, which is the type it must be if the attribute is used on a class. Then we must add the INotifyPropertyChanged to the class definition. Notice that our BooCustomer hasn’t implemented it, since it’s expecting us (the attribute) to do it.

Ok, lets add the code for that:

1
2
3
4
5
6

def Apply(target as Node):
	classDef = GetClassDefinition(target)
	AddInterface(classDef)
 
def AddInterface(classDef as ClassDefinition):
	classDef.BaseTypes.Add(SimpleTypeReference("System.ComponentModel.INotifyPropertyChanged"))

That was simple! Next we need to add the actual Event:

1
2
3
4
5
6
7
8
9
10

def Apply(target as Node):
	classDef = GetClassDefinition(target)
	AddInterface(classDef)
	AddEvent(classDef)
 
def AddEvent(classDef as ClassDefinition):
	notifyEvent = Event()
	notifyEvent.Type = SimpleTypeReference("System.ComponentModel.PropertyChangedEventHandler")
	notifyEvent.Name = "PropertyChanged"
	classDef.Members.Add(notifyEvent)

Here we create an event, set the right type, set the name, and simply add it to our classdefinition.

The last thing to do is to find all the properties, and add some code to the setter of those properties. This is how we find all the properties:

1
2
3
4
5

def AddToAllProperties(classDef as ClassDefinition):
	for member in classDef.Members:
		property = member as Property
		continue if property is null
		AddNewBody(property)

And to conclude it, we must implement the AddNewBody-method:

1
2
3
4
5
6
7

def AddNewBody(property as Property):
	oldBody as Block = property.Setter.Body
	property.Setter.Body = [|
		$oldBody
		if (PropertyChanged is not null):
			PropertyChanged(self,System.ComponentModel.PropertyChangedEventArgs($(property.Name)))
	|]

Ok, here’s something new. The [|...|]-tags. You probably can understand what is happening here, but not really why. The syntax is easy to both read and write. It’s called quasi quotation. I will describe it further in another post.

That concludes our attribute! Here’s the complete code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

import System
import Boo.Lang.Compiler
import Boo.Lang.Compiler.Ast
 
class NotifyPropertyChangedAttribute(AbstractAstAttribute):
 
	def Apply(target as Node):
		classDef = GetClassDefinition(target)
		AddInterface(classDef)
		AddEvent(classDef)
		AddToAllProperties(classDef)
 
	def GetClassDefinition(target as Node) as ClassDefinition:
		classDef = target as ClassDefinition
		if classDef is null:
			raise Exception("The NotifyPropertyChangedAttribute can only be used on classes")
		return classDef
 
	def AddInterface(classDef as ClassDefinition):
		classDef.BaseTypes.Add(SimpleTypeReference("System.ComponentModel.INotifyPropertyChanged"))
 
	def AddEvent(classDef as ClassDefinition):
		notifyEvent = Event()
		notifyEvent.Type = SimpleTypeReference("System.ComponentModel.PropertyChangedEventHandler")
		notifyEvent.Name = "PropertyChanged"
		classDef.Members.Add(notifyEvent)
 
	def AddToAllProperties(classDef as ClassDefinition):
		for member in classDef.Members:
			property = member as Property
			continue if property is null
			AddNewBody(property)
 
	def AddNewBody(property as Property):
		oldBody as Block = property.Setter.Body
		property.Setter.Body = [|
			$oldBody
			if (PropertyChanged is not null):
				PropertyChanged(self,System.ComponentModel.PropertyChangedEventArgs($(property.Name)))
		|]

Using that code, you can now write classes like this that actually implement the complete INotifyPropertyChanged-behaviour:

1
2
3
4
5
6
7
8

 
 
[NotifyPropertyChanged]
class BooCustomer:
	[Property(LastName)]
	lastName as String
	[Property(FirstName)]
	firstName as String

Try it yourself and look at the code through reflector to see what is really going on here. Remember to put the attribute and the classes using it in different assemblies.

Any comments on how to improve or clarify any of this will be appreciated.

The solution that prints alot of info on your attribute, and shows where you can place it: Boo AttributeExplorer-solution

- Tore Vestues

Say you want to make a new keyword in Boo, called “WriteHelloWorld” (yes, it’s an extremely bad example, but I want to keep it as simple as possible). Boo does not understand the word “WriteHelloWorld” by default, but you can make it understand. What you have to do is write a little “plug-in” to the compiler.

The “WriteHelloWorld” plug-in have to be implemented in a separate assembly from the assembly that is using the keyword. This is because the plug-in assembly with the “WriteHelloWorld”-functionality has to be run in the compiler and thus already be compiled during the compilation of your main assembly. I’ve added an illustration that I use in some of my Boo-presentations.

When your main assembly is under compilation, the “WriteHelloWorld”-plug-in will be asked for help every time the compiler hits the “WriteHelloWorld”-keyword.

I’ve implemented the WriteHelloWorld as a meta method, since it is the easiest way to create new keywords if you do not need to work with the ast-tree.

1
2
3
4
5

[Meta]
static def WriteHelloWorld():
	return [|
		Console.WriteLine("Hello World!")
	|]

This method tells the compiler that when it finds the “WriteHelloWorld” keyword, it should replace it with the code “Console.Writeline(”Hello World!”). And it does, if you look at the output assembly (using a tool like Reflector), you will see that this is exactly what the Boo-compiler has written. Remember that this is compile-time. Within the compiler process itself. The WriteHelloWorld-metamethod will never be executed run-time, it won’t exist after compilation.

Notice also that the main assembly has to reference the plug-in-assembly. If you do not do that, the compiler does not know where to find the plug-in.

This is how all extensions/plug-ins work in Boo. The compiler asks a plug-in to interpret what a keyword/attribute means, and gives the plug-in control of what to do. If you use Macros or Attributes you will also be able to access the compiler-tree, enabling you to manipulate the whole compiler process. For even more power you can add custom steps to the compiler pipeline, where you can do literally anything you want to with the code. More about that another time.

I’ve attached the solution that implements this. Read Getting Started to see what you need to run the solution.

Boo extensions explained Solution

- Tore Vestues

Microsoft decided that DbC should not be a part of the languages themselves, but rather it should be offered as a standard library. I think this is unfortunate. If it had been a part of the language, the syntax could have been more declarative, and it probably would have given DbC more power.

The problem with having DbC as just another library is that you do not get any keywords, it is not allowed to be as declarative as it could have been, and the syntax gets unnecessary verbose. And besides, if it is just another library then this is really old news. There are several DbC libraries available on the .Net platform already.

But Contracts is actually a bit more than just another library. I believe the Contracts-team, not being allowed (I suspect) to make it a part of the languages, really wanted the power anyway. And so they got creative, and did a couple of interesting things.

First, they made tools as a plug-in to Visual Studio, and these tools are there to support the library. Second they actually added post compilation. In Contracts, you define all the Contracts-library code in the beginning of the method for readability (making it more declarative). But for this to execute correctly some of the code (the ensure-part), has to be at the end of the method. What Contracts’ tools do is actually move that part of the code to the end of the method, after the code is compiled.

This is very, very interesting, and it raises the question: What is a library/framework? Normally it is just some code you can execute following the normal constraints of a language. What the Contracts-team has done is to extend the concept of what a library/framework is. They implicitly say a library/framework is both code and tools, meaning the tools can actually do some tweaking with the code after it has been written. In this case it is done for the sake of being declarative.

This means that when you create a library you get the power to add declarativeness to it, beyond the language. Now that is a very compelling concept! There are of course a couple of problems here. Creating these kinds of tools for your library is not a trivial task! Microsoft can do this because a) they’ve got the resources and b) because if all else fails, they can add support directly in the compiler, which they have already done on several occasions.

The pain here is of course, that Microsoft can do it, but you really can’t. It’s too much work, and you can forget about accessing the compiler. We as developers are not enabled to have this power.

I’ve been playing around with Boo for some time now, and I love the way Boo allows me to add keywords and to change things during compilation. My point is that Boo actually enables you to make frameworks that also incorporates tools the way the Contracts library does, and in addition it actually allows you to create keywords! And the best thing about it is that this is doable for all. It’s not very complicated. It really empowers us as developers to redefine the concept of frameworks.

If a framework can be functionality, tools and keywords then we enable us to write powerful, declarative, and less verbose code. Boo enables us. C#, sadly do not.

The very, very sad thing here is that during another session at PDC08, Anders Hejlsberg “hinted strongly” that such compiler extensibility will never, ever be available in C#.

To demonstrate “Contracts”, this is how DbC is implemented:

1
2
3
4
5

string GetDescription(int x) {
 Contract.Requires( 0<x);
 Contract.Ensures(Contract.Result<string>() != null);
 // Method body ...
}

You add a set of Requires and Ensures at the top of your method. The Requires-statements must be true at the beginning of the method, and the Ensures statements must be true at the end of the method. This means that the Ensures statements must be executed last. This is where Microsoft uses the post compilation to move that part of the code after compilation.

I have actually already made a little library for DbC in Boo, it’s very easy to do (probably only took me an hour or so to implement). This is how you say the same thing with my little library:

1
2
3
4
5

[Require(i<x)]
[Ensure(result!=null)]
def GetDescription(x as int) as String: 
	result as string
	// Method body ...

It’s got all the functionality of Contracts, it’s just as declarative (or probably even more), and in my own opinion it’s less verbose. And do not forget that it took me about an hour to implement the whole library! This is enabling developers to be more productive!

Why Microsoft does not want to enable us with this is beyond me. But regardless of Microsoft, there is nothing stopping you from using Boo!

-Tore Vestues

What makes Boo cool?

The cool thing about Boo is its no nonsense approach. I really enjoy its focus on a clean, wrist-friendly syntax combined with expressiveness and simplicity. Boo is actually inspired by Python, and combining the best of Python with the .net framework and statical typing is quite powerful.

Boo makes the compiler work for you. The philosophy is, if the compiler can figure it out, you shouldn’t have to tell it. For instance, Boo has an automatic Type Inference. If the compiler can figure out what type a method returns or a field is, you do not have to declare it yourself. You can write

1
2
3
4

def GetCount()
 return 1
 
count = GetCount()

instead of

1
2
3
4

def getCount() as int
 return 1
 
count as int = GetCount()

It’s not hard for the compiler to deduce that the getCount() method is returning an integer, so why should you have to tell it? That’s wrist-friendliness for you. Mind you, as long as the compiler can figure it out, both alternatives are valid Boo code. Then it is up to you if you want to declare the types or not.

Let’s look at the classic “Hello world” to demonstrate Boos expressiveness. In C# it is implemented something like this:

1
2
3
4
5
6
7

public class HelloWorld
{
 public static void Main(string[] args)
 {
   Console.Writeline("Hello, world!"); 
 }
}

In Boo, writing this line will do the same thing (you do not need a class or a method):

1

print("Hello, world!")

The Boo manifesto simply concludes, “The guys who came up with ‘public static void main’ were probably kidding”.

Although Boo is inspired by Python, it is not just another Iron Python. It’s much more than that.

What makes Boo great?

These are examples of Boo’s no-nonsense approach and there are many more examples of this. I really like that the language itself is built on this philosophy. But what really makes Boo great is its compiler extensibility. This means that you can write extensions that run in the compiler when your Boo code compiles. This powerful feature enables you to actually extend the Boo language itself.

There are several ways to do this. You can write syntactic attributes. They look like regular .net custom attributes, but they are not. You can also make new keywords either with syntatic macros or meta methods. If these techniques are not fitting your needs you can hook up to the compiler pipeline and do virtually anything you want to with the output of the compiler process.

What all these techniques have in common is that custom code is run during compilation of your Boo code, and this custom code changes the output. The compiler takes the code as input, and asks your extensions to do their magic, and then creates the output which normally is an assembly. The magic your extensions do is to basically change whatever you’d like, giving you control of the output.

The great thing about this is that compiler extensibility is an excellent tool for removing boring, repetitive boiler plate code. This enables us to increase our productivity. Let me demonstrate how:

INotifyPropertyChanged

I hate implementing the INotifyPropertyChanged interface. To implement it I have to write a lot of boiler plate code. And as we all know, boiler plate code is boring to write, it’s often harder to maintain, and it bloats your otherwise elegant code. This is a problem since you need to implement the INotifyPropertyChanged interface to be able to use .Net’s data binding, and I have come to realize that data binding is an extremely nice tool when used correctly.

For those of you not familiar with Data binding and INotifyPropertyChanged: Data binding is about one object wanting to know when something changes in another object. It is really an effective implementation of the observer-pattern. Often this is used when a gui-control wants to know if the object it represents changes. To do this the gui-control is databound to the object it represents. In order for the data binding to work, the observed object needs to implement the INotifyPropertyChanged interface. This is all very nice and effective, except for all the boiler plate code in the observed object.

This is basically how the observed object is supposed to implement the INotifyPropertyChanged interface in C#:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

public class Customer: INotifyPropertyChanged
{
    private string firstName;
    private string lastName;
 
    public string FirstName
    {
        get
        {
            return firstName;
        }
        set
        {
            firstName = value;
            NotifyPropertyChanged("FirstName");
        }
    }
    public string LastName
    {
        get
        {
            return lastName;
        }
        set
        {
            lastName = value;
            NotifyPropertyChanged("LastName");
        }
    }
 
    public event PropertyChangedEventHandler PropertyChanged;
 
    private void NotifyPropertyChanged(String info)
    {
        if (PropertyChanged != null)
        {
            PropertyChanged(this, new PropertyChangedEventArgs(info));
        }
    }
}

Man, this is simply too much code for just notifying when some properties change! I honestly do not believe that Microsoft is proud of this. The problem is that the language does not allow us to simplify it. Sadly this is probably the best solution within the mainstream .Net languages. Believe me, I’ve been looking for better ways to do this for more than a year, and I haven’t found a substantially better way. But that was before I found Boo. Because Boo is different. Boo gives you possibilities where other languages and frameworks must give in.

Let’s analyze the INotifyPropertyChanged-implementation. What is it that we really want to do? We want to notify when a property has changed. If we think a bit declarative, this should only be one line of code: “Notify observers when properties change”. And with Boo, you can actually do that. I’ve implemented a syntactic attribute called “NotifyPropertyChanged”, and when you tag your class with it, all the boiler plate code is added at compile time, so you no longer have to bother with the details. Look at this:

1
2
3
4

[CreateProperties,NotifyPropertyChanged]
class BooCustomer:	
	public LastName as String
	public FirstName as String

Can you believe that this code does the same as the C# code above? Well it does. I have extended the compiler with two attributes. When the code compiles, the “CreateProperties”-attribute takes all public fields and turns them into properties, and the “NotifyPropertyChanged”-attribute adds all the code for notifying about the changes. When this code hits the compiler, all the boiler plate code is added to the output, leaving your code simple, clean and elegant.

I won’t go into the details here on how to create these compiler extensions, but I will say that it is a lot easier than you might fear. And as an additional goodie, you can write these extensions in any .net language you’d like.

The INotifyPropertyChanged example is just one example. I feel that repetitive boiler plate code is introduced more and more these days. The problem with this kind of code is that it’s hard to remove it with our mainstream .Net languages. Boo is the perfect tool for removing this kind of code. I believe that these possibilities can substantially increase our productivity in enterprise systems. That being said, I do not see Boo as a mainstream language in the near future. This is partly due to the lack of good tool support, and that the community is still too small. Instead I see Boo as a language that will be used in some suitable layers or components in a larger application written in a mainstream .Net language.

If you’d like to look into Boo, I recommend you start at the Boo homepage.

- Tore Vestues

Development environment

For the time being I recommend you do your coding in Sharpdevelop. Download and install the latest here. You should also download the latest Boo-distro (the binaries), and move (and overwrite) the Boo-files into The sharpdevelop install-folder: SharpDevelop\3.0\AddIns\AddIns\BackendBindings\BooBinding. Now your development environment is in place.

For Visual Studio integration, Boo Lang Studio is the thing. But sadly I don’t find it stable enough yet.

The source

Yes, you should download the Boo source code. It’s helpful to use it to browse class hierarchies, to see how things actually work, and most importantly, the source contains a lot of example code. I actually learned macros by looking at the source code for the built in macros (print, assert etc).

The compiler extensibility

To fully understand how Boo works with the compiler, it’s very helpful to be able to inspect the result. That is, the assemblies that are produced. There is an excellent tool for doing that, Reflector. Download it, and start looking at the compiled assemblies you produce.

Starting points

You should start at the Boo homepage. Also take a look at Ayende’s blog. He blogs quite a bit about Boo.

- Tore Vestues

I know that Iron Python and Iron Ruby are sailing up as really exciting alternatives to what we are used to with their dynamic nature and neat syntax (among other things!). But there is yet another language with some unique and mind blowing features that I actually think can rise above all these languages. It’s simply called Boo. And with Boo, I really think we can make a difference when it comes to productivity.

Boo isn’t actually a new language, it’s been around for some five years now, but it has not become a mainstream language, yet. Well, now it’s positioning itself as “the” language for building DSL’s (domain specific languages). And it almost certainly is. Given also that DSL by many is thought of as “the future”, this by itself actually makes the future of Boo quite bright. That’s great! But as DSL is sailing up as the buzz of the year, there is something many actually overlook in Boo: It’s an extremely powerful language by itself, dsl or not!

What makes it so powerful is its compiler extensibility. Combined with the no-nonsense python style and syntax, this language rocks! The essence of the compiler extensibility is that Boo makes it very easy to write code that is executed in the actual compiling process. This is actually a form of code generation, except you do not generate the code, you change the generated output from the compiler. So how does this make us more productive?

To give you a little taste:

1
2
3

[Singleton]
class TheSingleton:
   pass

This is how you create a Singleton-class in Boo. It can’t be simpler, and it’s way less code than in any other Singleton implementation I’ve ever seen. That’s because Boo gives us a chance to easily extend our language, which few other languages can. The Singleton attribute you see is not a normal attribute, it’s an AST attribute, which means when the compiler find it, it executes some code, which in turn adds all the functionality to the class when it is written into the assembly. Did you read my post about the declarative mindset? Boo is spot on declarative: we state what we want to do (”make a singleton”), and we simply do not have to write the actual implementation. And why should we? Every singleton is implemented just the same way. It’s no need to do it more than once. Boo makes this not only possible to handle elegantly, but also easy. I love it!

To be honest, I haven’t been this excited about technology in a long time, and I’ve decided to focus on Boo in the time to come, simply because I believe this might be the star of tomorrow.

This means I will be posting code and tutorials about it, doing research, joining the community, and hopefully making a tiny bit of difference, doing my share of pushing the world in the right direction when it comes to developing better software.

So, don’t hesitate, join the fun. It’s right here: Boo!

- Tore Vestues