Freeform - a meta language that allows defining and extending syntax inline.
freeformlang.sourceforge.net
freeformlang.sourceforge.net
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/
1) you'll never be able to learn the complete syntax to the "language".
2) all statements are ambiguous without knowledge of supporting code. Like what some say about operator overloading, but even worse.
3) what syntax do you write your own code in, if it's closely involved with two different libraries that use different syntaxes?
4) what if two different libraries use the same syntax to do different things?
Does anyone know what the philosophy on these points is for meta-languages?
1) Well, in FreeForm you just look at the language sources to see the syntax, e.g.:
http://freeformlang.git.sourceforge.net/git/gitweb.cgi?p=fre...
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
exp glued = my.sql.glang(glued)|my.ipc.glang(glued)|my.glang(glued);
Even more, you can make even that extendable:
exp gglued(ext) = ext|my.sql.glang(glued)|my.ipc.glang(glued)|my.glang(glued);
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.