The project's goal is to build an OS, GUI, programming environment, editor, and internet stack in under 20K lines of code. They've had some big wins. To implement TCP/IP, they built a grammar to directly read the block diagrams from the RFCs, and simply pasted them in.
The dynamic grammar system, called OMeta, is just one part of the project. See the "writings" section from the above link for papers, and "software" for running code. You can find more on OMeta itself here: http://tinlizzie.org/ometa/
Thank you for pointing out OMeta, that project looks amazingly useful. Especially since it's original implementation is in JavaScript. Which means I can (fingers crossed) easily drop it into a project I'm working on...
You will be using the syntax you explicitly specified. The fact that you can use more than language, doesn't mean you have to use languages or language extensions you are not familiar with. I'm not certain, why this should be a problem. If there is a syntax package you'd like to try, there is inevitably some learning required, similarly as with the new libraries.
2)
Well, you are right, both the problems and benefits of operator overloading are present. Still, as a C++ programmer, in many cases, the benefits far outweight the price (especially with smart pointers). Also, like with C++ operators, to see how the notation operates, you can just check out the code. But I have to admit, that the ability to define & extend syntax comes with a great responsibility. I'd still see situations, where the mechanism would be useful.
3)
It is possible to have generic expressions, that take parameters. E.g. let's imagine, that we have some extendable core language set (e.g. my.glang) and several extendable extensions to it (e.g. my.ipc.glang, my.sql.glang).
In current code, to glue it all together you can do
4)
Well, in previous example, one automatically will set priority between languages. So, if the sql syntax uses some foobar@zap syntax, while the mt library uses the same, the sql syntax will be chosen. Still, ofc. this kind of hiding of expressions have its own problems, and I believe that the only real way to manage such issues is with careful language & extension design. Still ofc. if there are syntax packages from two different parties, syntax clashes may result. Still, as the syntax definitions tend to be highly modular, even in such cases you may be in position to create your own coherent language package by cherry picking some syntax from here and there.
Ease of use: to make syntax changes this radical in Common Lips you'd have to write your own reader which parses the new syntax. That's a pain so most people stick with what you can do with macros (and, sometimes, simple extensions to the reader).
That is really neat. I'd been fighting with writing a scanner/parser for the first time and finally gave up -- this might scratch the itch that prompted me to do so in the first place.
The project's goal is to build an OS, GUI, programming environment, editor, and internet stack in under 20K lines of code. They've had some big wins. To implement TCP/IP, they built a grammar to directly read the block diagrams from the RFCs, and simply pasted them in.
The dynamic grammar system, called OMeta, is just one part of the project. See the "writings" section from the above link for papers, and "software" for running code. You can find more on OMeta itself here: http://tinlizzie.org/ometa/