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

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

  1. Roger,

    Thanks for taking the time to weigh in.

    In looking at both your post and Frans’, I think we’re not being super-clear on our side when we talk about M and textual DSLs.

    While it is possible to write the grammar for a “capital-L” language in M, that’s not where most of us on the team see the primary use case of M.

    Rather, the sweet spot (in my mind at least) is in enabling tailored syntax over schematized data – that is, the schema dominates the design, not the language per se.

    In M, you can define a schema and get a “default” syntax for values, but, as with XML, JSON and S-exprs, that syntax lacks visual cues from the domain. For people that want a more tailored syntax, M allows them to write a grammar to “transform the data” from linear Unicode to structured data.

    Independent of the design center, you raise a valid question as to whether developers can write grammars.

    I love that question and my team is working hard to make the answer “yes” for as large a body of developers as possible. We have a lot of work to do, but I’m pretty hopeful we can advance the state-of-the-practice enough to make the effort worthwhile.

    Thanks again for taking the time to weigh in.

    DB

  2. Generating a parser from a grammar is the easy part.

    The hard stuff is the language design and its affordances (including error recovery). In other words, deciding how to engage the target audience and what to build…

    I don’t think M intends to really help with the problem of (domain-specific) language design. As you said, it seems better suited for data transformation tasks. I’ve seen plenty of cases where programmers used overcomplicated and slow “regular expressions” to extract and transform structured data for lack of a neat way to express a grammar.

    That said, I’m getting a little tired of markup, notations, schema definitions, and grammars for data. What about semantics? What about behavior?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s