“So when I look at M's elements, I can only conclude that it too has the same aspects as the well known tooling and building blocks for parsers, grammars and the like available to everyone today: it's complex. With 'complex' I mean: you need proper knowledge about computer languages, parsers and grammars to understand what's going on and how to use the tools available properly. There's nothing wrong with that: if something is hard, well... that's life, deal with it by understanding the concepts which makes a hard problem manageable. Though to me it's impossible that all crucial aspects of writing computer languages are suddenly not important anymore with M's elements on the table. Sure, people will write DSLs with M's elements, but today you can do that too with ANTLR or Gold Parser, use a visual toolkit to design, test and debug the language, and you're likely up and running in a day or two. That doesn't mean a person who has no clue what LL(k) means, what an AST is, can create a language for a given domain with ANTLR, some knowledge about parsers, grammars etc. is required. And with M's elements, this isn't any different at all.” (Frans Bouma)

 

M makes it easy to define simple grammar and give your free parser and an AST built as a result. Then what?


That’s the whole crux of the challenge lies. M takes you 30% there in making hacking grammar easily but you still have to create the machine that will perform on that given AST (or what they call MGraph) and that takes a lot of code, etc.

The first success for M will be apparent on the percentage of people using M to build custom configuration directive (as this is the simple scenario for M) instead of putting all the configuration information in XML format. But that’s just a low hanging fruit. The higher goal is how to make it easier for developers to develop the machine behind that will perform the DSL.