Frans Bouma posted an entry about Oslo’s M, and if I’m reading it right, he is highly skeptical about it actually making creating Domain Specific Languages (DSLs) any easier.

In part, Frans has a point. Yes, it is true that writing a good, complex language is hard. Yes, there’s a bunch of compiling-writing stuff that isn’t exactly trivial. And yet, this isn’t necessarily the point.

There are a couple of places where I don’t fully agree with Frans:

Yes, writing a complex, full featured language is hard. But writing a simplified grammar can get you a long way towards simplifying certain class of problems, and I do think there’s a lot you could do if the right tools where there for you. Because, let’s face it, most compiler writing tools suck.

The second part is that while Frans talks about M in general, in reality he’s only referring to a single part of it: MGrammar. There’s a lot more to M than just writing DSLs, and I thought it was important to bring this up.

The third and final part is that, well, it’s not clear if Frans has actually tried to use the M stuff. I’ve been playing a bit with MGrammar since the PDC and I have definitely been very impressed so far with how much you can do even without knowing much about writing compilers or formal grammars.

The way that MGrammar grammar’s (pardon the redundancy!) are writing is actually fairly intuitive most of the time, and the built-in conflict resolution rules actually seem to work well in the samples I’ve tried so far. So in that sense it is definitely a lot nicer than many compiler writing tools.

I also liked very much liked how you separate the parsing aspects of things (i.e. defining the grammar) and how actually doing something with the parsed stuff is a secondary step (and one you can actually tackle after that if you want). It’s very clean and works well in many cases. It also means that MGrammar is easy to use if you only want to parse some [unstructured] data and do something with it; and not necessarily “execute it”.

And finally, there are a couple of hidden gems that I thought can really make a difference once all the tooling is there. For example, I love how you can annotate your grammar to be case-insensitive with a simple attribute:

module DLR {
    @{CaseSensitive[false]}
    language ToyScript {

Or even annotate token definitions with colorization information that Intellipad picks up and uses right away:

@{Classification["Keyword"]}
final token Print = 'print';

In short, I agree with Frans that if you’re looking into creating a full, complex language, then yes, MGrammar by itself won’t make much of a difference. But I do think it shows a lot of promises for the slightly lower-hanging fruit of many simpler DSLs by making it easier to get started writing the grammar and seeing it work right away.


Tomas Restrepo

Software developer located in Colombia. Sr. PFE at Microsoft.