Oslo arrived just in time for Halloween, and it brought many more treats than tricks. Now that I've had some time to play with M, Mg, Intellipad, and the rest, I've got a list I'd like to see Santa bring. I've spent the most time with Mg (also known as "MGrammar"), so I'll focus on it.
For those who aren't familiar, a preview release of Oslo was shipped this fall. It includes the Mg language, which is a language for defining languages. You write down what syntax you want and Mg produces a parser for you. It's simple to use and really lowers the barrier for creating "Domain Specific Languages" which solve specific problems (see my previous post for a small tutorial).
I suspect most uses of Mg will start out as "generative." That is, Mg will be used to define a simpler syntax for some more verbose format. The support provided in the SDK for that kind of use is adequate, though minimal. But what about real languages? That is, what if you want to actually program in your new language?
In the "generative" use case, the CLR is your runtime and you don't need much beyond what it gives. A programming language, on the other hand, has its own execution model, semantics, environment assumptions, etc. Managing state, avoiding naming conflicts, and providing a consistent programming experience are not easy. Right now, Mg users are going to have to invent these thing themselves.
Even if an language starts out simple, with no apparent need for a systematic approach to the issues above, I suspect they will want it eventually. The maintainers may not have background in language design and not realize that they are reinventing the wheel. In theend, the language will most likely work but its "runtime" will be a nightmare to maintain.
If the Oslo team provides a toolbox addressing these issues from the beginning, I think they'll save us all a lot of pain. The following is my Oslo Christmas list -- essential tools they can provide to help us all become language designers.
A language for defining types
The first present I'd like to see under my tree is a consistent way to describe typing for a given language. Most users of Mg will probably be familiar with .NET, so why not start by allowing me to describe simple OOP concepts? Then find a way to attach that to my language. Even something that made sure I didn't try to add an integer to a string would be a good start.
I am not sure how compositional Mg is, but is it possible to import type annotations into my language? I suspect not. Perhaps a better approach is for the team to provide a language for defining typing relations and a tool for checking a given AST against that definition. Productions are very flexible so perhaps the tool could use annotations in my productions to ensure the types remain consistent?
I suspect this is something that many, many languages are going to need and they'll implement it one way or another. But an ad-hoc type-system implementation (especially when you don't know you've got one!) is almost worse than none at all. In the first case you have only the illusion of safety; in the latter, at least you know you're flying blind!
I've got my language defined -- now give me a way to run it. An "execution model" is important for all but the most trivial of languages, even those that just transform one format to another. If the Oslo team gave us a few interpreters with different execution models, we can design our languages to the specification that makes the most sense. A couple of models come to mind.
This intepreter would takes as input a tree and evaluate it according to rules provided by the language designer. The evaluation would produce another tree which could be persisted (e.g., an XML document) or could even be evaluated according to another set of rules.
Many pure, functional languages are implemented with this technique. Techniques for layering in mutability, environment, or I/O are known and could be provided as extensions to the basic interpreter.
This intepreter views the language as a set of statements, executed in order. Support for labeling, branching, and function calls are provided. Execution runs in the context of some environment which can be modified by the statements executed. For simplicity, the environment can be global. A more complex interpreter would allow local environments to be maintained. I/O primitives will be built-in, so the scripts can be used as part of a processing pipeline. Access to CLR objects could also be provided, according to a mapping given by the language designer.
This interpreter would be useful for batch-like processing scenarios where a general-purpose language is too unweildy. Transformations in a build or asset pipeline come to mind.
This interpreter is designed to add scripting to an application. To make the interpreter feasible, only allow .NET applications be the host. The interpreter is given a map from application objects to productions produced by the language. Additional configuration defining how those objects are named and manipulated in the languge would need to be given. Finally, execute the scripts by mapping entry points between the application's objects and the hosted language. This would give a great way to provide event-based scripting in any application.
VBA also provided a full development environment. I don't know that a complex IDE should be included by default, but services such as separate code modules, debugging and interactive use (i.e., "REPL") would definitely be useful.
This may be the most important item on my list. Mg is very impressive technically and I'm sure any programmer who looks at it will start drooling. But what is it good for? That's the question the Oslo team needs to help us answer. I'd like to know where they see their product having the most impact. What scenarios did they have in mind when they were developing it? Who's using it internally and why?
It might also help if the team talked about their inspiration. What came before that they modeled Mg after? Where did those approaches go wrong and what have they done to improve the situation?
Mg and the rest of Oslo are an amazing piece of work so far. I can't wait to see what Santa brings next year -- I just hope I don't have to wait that long.