Here is a small, but interesting tidbit. Yesterday I have finally sat down and documented a lot of the changes that I made in Brail recently, I was surprised to see how much I had to document:

• Auto Imports
• Strongly typed variables
• Sections
• The "?variableName" syntax
• Symbols
• Null Propagation

The last part is what I want talk about now. Brail is a .Net language, which means that something like this:

output user.Parent.Name

will raise NullReferenceException if the user's parent is null. That can be somewhat of a pain in many scenarios. Brail now has a better syntax for this:

output ?user.Parent.Name

 will ignore any null values that it encounter in the way. It is will either output the parent's name or nothing at all.

The small print:

This will work only for variables that you get from the controller via the PropertyBag or Flash. You can't use it on variables that you define in the view. However, that is rare enough that I don't think that it is going to be a problem.

Note that I didn't document the DSL support in Brail yet, that is going to wait until it is stabilized a bit.

Harris has more details about the internal implementation of Brail's DSL Support

• DSL Support in Brail, Part I
• DSL Support in Brail, Part II

Following the same line of thoughts, Alex has a similar implementation using C# 3.0. Personally, I think that Alex's implementation is cool, but it looks really similar to LISP, and that sort of scares me. I am currently reading about ANTLR, so it actually makes sense, in a weird way, except that I keep looking for the lower level implementation.

And as long as I am busy in link aggregation, Tom Opgenorth has posted a guide to Binsor, including a Getting Started example!

The technical details are going to be of interest to a limited number of people, but it comes down to a design choice that I made when I first wrote Brail. It has to do with how the text is outputted into the compiler, and some tricky bits that can happen there because Boo's compiler understand that "this is ${code}" and can turn it into the correct string, based on the value of the variable "code".

That was fine until I realized that I can do more than a simple variable substitution in there. You can call anything that returns a value, which is very valuable for code such as:

The problem started when the code inside the expression got even more complicated. No longer a single method call, but method calls that wanted to pass string parameters (with " in the middle), or maybe they wanted to use inline expressions as well. I always work-around those issues, but today I got a piece of code that was too pretty to give up on, so I fixed the Brail pre-parser (thrice, until I got it right) so it would output the correct code to the compiler.

What this basically boils down to is that this is now valid code:

If you are interested, the output of this is:

I like it.