Domain Specific Languages

Dave Thomas talks about code-generation/DSLs here: http://www.codegeneration.net/tiki-read_article.php?articleId=9.

This dove-tails with a bunch of recent thoughts regarding QVT vs templating and the whole cumbersome pain of defining Models, instantiating Instances, and then working with them.

I suspect this would really be a whole bunch easier if the standard EMF editor allowed “import” of other Models into the ResourceSet, but it may go deeper.

For example, what one often wants for a DSL is a printer/parser for some textual form since one can then blast ahead with just using it. HUTN might be okay, but something akin to AntiAntiYacc would be preferable. The downside is that then you need to define the grammar and likewise for AntiYacc. This is kinda tedious and leads to the reason why Lisp, Prolog, Python/Perl, and (I guess) Ruby are handier — you can just re-use and extend the existing syntax and you get your parser (and maybe printer) almost for free. And the Model? We don’t need no stinkin’ Model, we’ve got the language’s own native type system (meta-model) to use.

What does this say about the MDA approach (as exemplified by MOF/UML and QVT)? My current gut feel is that MDA gives you impedance mismatch on the way in (parsing) and the way out (printing). Maybe this is the real contribution of Microsoft’s Intensional programming work — reducing the impedance mismatch.

Post a Comment

You must be logged in to post a comment.