Meta Programming System
Expression system - best approach?
I have a project where I need a full expression language, but the target of generation is XQuery. I'm trying to decide what would be more efficient:
1) extend base language and use those concepts, then map the concepts to XQuery in the generator or
2) just roll my own expression language following the Xquery/XPath specs, referring to base language for ideas if I get stuck
The problem I see with #1 is that the whole java language is available and potentially has to be mapped, and some concepts may not map cleanly to Xquery. Also, I have to map everything up front, or build in a lot of constraints to restrict the base concepts that are available. Plus, I'm just not sure if base language is meant to be used that way.
I could see #2 allowing a more incremental approach,like start with a few simple operators and stuff, then add more advanced concepts if and when needed. My fear here is hitting a wall as more concepts are added and the complexity mounts, or eventually end up replicating most of base language.
I'm leaning towards #2, and I've started building an XQuery language based on the spec, which I would build my language on top of.
But before I get too far down that path, I thought I would ask for suggestions. It's awfully tempting to extend base language, inheirit from Expression and then sort it out in the generator.
You can use baseLanguage's expression part separately from the rest of baseLanguage by defining canBeAncestor constraint in your expression's container (I suppose you have one). This will allow to filter out all the concepts you don't want to be used in your expressions.
But I would rather think about what will I reuse from BL's expressions. If the only think you want to reuse is structure of mathematical operations and comparison operators, maybe it would be better to write a new language. If you also want other concepts to be available inside of your expressions, the BL's typesystem or copy-paste functionality from BL, or maybe something else because of your expression have the
as BL's - then you'd better reuse existing.
Thanks Mihail. I've pretty much reached the conclusion that not reusing baseLanguage is the best approach. I can always use BL as a reference for the things I'm not sure how to model.
go to parent
I've had the same problem. I decided to reuse BL expressions and I don't regret it.
Removing not supported expressions by constraints is not such a big deal. For me it was more difficult to remove their actions. But the solution for this you can see here:
I have defined an array of concept where I specify the supported expressions. I use this inside my constrains and for my actions. So I can just incremental support a new expression by defining its generator and extend my array.
I think it's not such an easy task to create all this editor magic and type checking for your own expressions. And then you must also care for yourself for the operator precedence (have a look at
I would advise that you implement your own expression language if you like to learn how to do it. But if you need an expression language with similar semantics to java as fast as possible, then reuse the existing one!
For me it would be better if more people use baselanguage in their languages, because I guess BL will get less bugs then ;). (I don't want to blame the BL devs, I know (now) that creating complex languages even with a tool like MPS is not a trivial task.)
Fabma - excellent points. I may have to rethink my decision to write my own.
What I would love to see is baseLanguage more modularized. Basically decouple the expression and type systems into a separate language, with the Java implementation extending that. I think that would help situations like ours a lot, and I suspect we're not the only ones.
go to parent
Maybe you want to have a look at mbeddr. we have modularized our languages quite a bit. The expressions part can be found here:
I'd suggest. Mbeddr team are cool guys, they always find good solutions ;)
IntelliJ IDEA 12 / MPS 2.5.3 Plugins / OpenJDK 18.104.22.168 / Fedora16
Warning message - without further description...
Build #178 (Dec/17/2014 3:47PM)