| XText alternatives for DSL-2-JVM chain [message #1767117] |
Sat, 01 July 2017 09:17  |
Eclipse User |
|
|
|
Hi,
unfortunately I had to drop out a project I started in XText because of lack of support in XText/ANTL3 for Unicode beyond the Basic Multilangual Plane.
Can you suggest Eclipse-based alternatives to XText for the following scenario?
DSL source -> Abstract Semantic Model 1 -> Abstract Semantic Model 2 -> JVM bytecode
So, basically, I need to provide my client with an Eclipse-like IDE and a DSL language that, after certain (complicated) model-2-model tranformations, will compile into JVM bytecode.
Suggestions much appreciated!
David
EDIT: I am asking rather about the first part of the chain, the text-to-model one. I need a replacement for XText.
[Updated on: Sat, 01 July 2017 09:38] by Moderator |
|
|
|
| Re: XText alternatives for DSL-2-JVM chain [message #1767123 is a reply to message #1767121] |
Sat, 01 July 2017 10:04  |
| Eclipse User |
|
|
|
Thanks again. Your quick and insightful answers are saving me a lot of time and nerves! :)
Quote:I still don't known what you mean by JVM byte code. Do you really plan to write you own byte code generator? If not, then write "-> Java".
That's indeed the long-term goal, JVM bytecode. I've done it in the past (using the ASM library), but not in the context of Eclipse Modeling Tools.
However, for the time being and a first prototype, I'll rather stand by Java or Scala code generation. So I will keep in mind your suggestion for being more precise when I write about my model-2-text step.
Quote:The inadequacies of extended Unicode support in one tool are a fair indication of the state of the art. You can probably try something else and get exactly the same or worse problems.
Unfortunately I am beginning to see that you are right in this. I've been spending some hours looking for an alternative to XText without nothing free of similar problems or, as you say, worse flaws. I thought Spoofax might be the one to go with but it does not support Unicode at all.
Quote:If you really want all characters temporarily introduce an escape character analoguous to \t etc.
Yes, that might be a way to go. If today I can't find any obvious alternative to XText (and most probably I won't), I will just add some escaping mechanism for unicode chars into grammar. Then I will probably hook in a first pre-processing tool before the ANTLR parsing entry point that will translate end-user-written extended unicode chars into those escaped sequences that XText/ANTLR can handle.
Cheers,
David
|
|
|
Powered by
FUDForum. Page generated in 0.26511 seconds
Home