Even though I bashed M Grammar in my last post, I’m sort of starting to get what the fuzz is all about now.
I still claim that writing grammars is hard, and that the M Grammar language itself doesn’t do much to change this.
But the beauty is not in the parser nor the syntax, it’s in the tools.
The sweet spot of M Grammar is the Intellipad editor shipped with the PDC Bits.
Intellipad, unlike the editors for most other parsers, will give you real time feedback on your progress.
You can alter your grammar and see how this affects the parse tree for the given input.
You can also annotate your grammar with syntax highlighting hints and thus let you see exactly how the parser handles your input text.
Intellipad will aslo show you where your grammar suffers from ambiguity by underlining the bad parts with red squigglies.
In Gold Parser which is the parser framework that I have used the most, you will have to compile your grammar and hold your thumbs that there is no ambiguity in the syntax.
The grammar compilation process in GP is quite slow and will only give you some semi obscure feedback on what ambiguous definitions you have.
So I have to admit that Intellipad beats GP big time with its quick and intuitive feedback system.
I haven’t yet played enough with the M Grammar .NET parser to be able to give a fair comparison between Mg and GP when working with parse trees in your code, I will skip this for a later post.
If you have worked with GP before, you won’t have any problems adapting to Mg, the “grammar grammars” are almost identical, with the exception that Mg is slightly more verbose and GP relies more on symbols.
I was able to port a GP grammar to Mg in just a few minutes.
The ported grammar is the “GP. Simple” grammar.
You can find the original GP grammar definition here.
And the converted Mg grammar definition here.
At a first glance the Mg grammar might look much more bloated, there are two reasons for this:
1) There are currently no predefined char sets in Mg (AFAIK)
2) The Mg version also contains syntax highlight annotations.
A screen shot of the Intellipad input pane with the “GP. Simple” grammar highlighted is seen here:
By just looking at the input pane when editing my grammar I can assert that my grammar is somewhat correct, I do not have to analyze the parse tree every time I make a change to the grammar.
So in short; Writing grammars are still hard , M Grammar is a pretty standard EBNF engine, but Mg’s tool support beats GP’s toolsupport..
//Roger
Roger Johansson Blog 
GP is LR based, so it has to generate the action/goto tables before it can say anything about the grammar properly (as problems crop up during that process, as it’s otherwise too complex). Mg’s therefore very likely to be LL* based, similar to ANTLR. The ANTLRWorks toolkit is also very cool and allows you to visualize things ‘as they are at that moment’ as well, completely with step by step debugging of the complete parse process of the language.
But I think that all that is nice and all, but doesn’t take away the real problem: WHICH terminals and non-terminals to define and how exactly to be able to parse a given example text which is then accepted as valid AND for example make sure another text isn’t accepted as valid.
Frans,
We target a GLR engine.
The M compiler compiles language definitions into a binary form (an MGX file).
You can initialize our engine from that form and then start parsing input text to produce graphs.
Yes, your language definition needs to specify the rules for turning text into graphs.
Whether people will find that language easier or harder to use than writing a recursive descent parser by hand remains to be seen. Early indications have been promising, but these are early days.
I will say that from our experience building the M language family that authoring parsing rules has by no means been the hardest part of building the language :-).
DB