M Grammar Vs. Gold Parser


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:

dslhighlight

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

I call B.S. on the Oslo “M” Language


There was alot of hype around the new Oslo “M” language during the PDC.
It was pretty much explained as a new way to let people create their own domain specific languages.

Since I have a bit of fetish for parsing and DSL’s I attended to the “M Grammar” presentation.

They began by explaining that “M” is so easy that everyone and his mother will now be able to create their own DSL.
And ofcourse they had to show some trivial example that actually wasn’t a DSL at all, but merely a data transformer that transformed a textual list of “contacts” into a structured list.

Maybe I’m just stupid, but when I hear “new” and “easy” I don’t really associate that with old-school LEX and YACC BNF grammars.
But MS apparently do.

Just check this out, this is a small snippet of M Grammar definition of the language itself:

  syntax CompilationUnit
       = decls:ModuleDeclaration*
         =>
           id("Microsoft.M.CompilationUnit")
           {
               Modules { decls }
           };
  
  
   syntax ExportDirective
       = "export" members:ParsedIdentifiers ";"
         =>
         id("Microsoft.M.ExportDirective")
         {
             Names { members }
         };  
  
   syntax ImportAlias
       = "as" alias:ParsedIdentifier
         => alias;
   
   syntax ImportDirective
       = "import" imports:ImportModules ";"
         =>
         id("Microsoft.M.ModuleImportDirective")
         {
             Modules { imports }
         }
                 | "import" targetModule:MemberAccessExpression "{" members:ImportMembers "}" ";"
           =>
           id("Microsoft.M.MemberImportDirective")
           {
               ModuleName { targetModule },
               Members { members }
           };
   
   syntax ImportMember
       = member:ParsedIdentifier alias:ImportAlias?
           => id("Microsoft.M.ImportedName")
           {
               Name { member },
               Alias { alias }
           };

The grammars in “M” was essentially a hybrid of old BNF definitions mixed up with functional programming elements.

I’m not saying that their approach was bad, just that it wasn’t really as easy as they wanted it to be.
There are a few gems in it, but it does in no way lower the compexity of defining a grammar in such a way that everyone will be able to create real DSL’s.

Maybe some people will create a few data transformers using this approach, but I don’t expect to see more “real” DSL’s popping up now than we have seen before..

//Roger