Freeform - a meta language that allows defining and extending syntax inline.(freeformlang.sourceforge.net)
freeformlang.sourceforge.net
Freeform - a meta language that allows defining and extending syntax inline.
http://freeformlang.sourceforge.net/
5 comments
Sounds like a cool idea... but seems to have some immediate problems to me:
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) 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?
author here
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.
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.
What does this have that Common Lisp doesn't?
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.
Yeah, I got paste all that. It was the compilation stage that was the real brain bender.
Maybe you should start with a language in which compilation is simple, like Forth: http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/
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/