Home » Modeling » TMF (Xtext) » XText vs. traditional parser generators and template engines
| XText vs. traditional parser generators and template engines [message #37014] |
Sun, 05 April 2009 19:58  |
 Harald Wellmann
Messages: 34
Registered: July 2009
Location: Hamburg, Germany |
Member |
|
|
To me, the potential killer feature of XText compared to other parser and
code generator tool chains seems to be the automatic generation of an
editor component.
The perspective to get an editor and an Ecore model and some more for free
is rather appealing, but on the other hand, there are a couple of crucial
points that seem to be either undocumented or even unimplemented in XText.
Thus, given an existing language and an existing code generator, it may be
easier and faster to learn about code formatting, syntax highlighting and
outline in Eclipse and implement your own editor component manually,
rather than trying to use XText, spending resources on it you might have
better used for your manual implementation only to realize that some of
your requirements are not supported at all.
Over the years, I've worked with quite a few parsers and code generators,
both as a user and as a developer, in diverse flavours, based on nothing
but C code, or yacc, PCCTS, ANTLR 2 on the parser side, and nothing but C,
or XML, XSD, JET templates, Velocity, Freemarker on the generator side, so
I know there are plenty of ways to get a job done, but I'm not yet
convinced that XText and friends will do so.
Let us take a non-trivial example: I'm currently working on and with
DataScript, a language and toolset for specifiying binary datatypes.
(http://datascript.berlios.de), sporting a parser based on ANTLR 2.7 and
Freemarker generators for Java code and HTML docs.
(Or just take Java as an example - the complexity of these two languages
is more or less equivalent.)
- There has to be a non-intrusive way of merging partial models from
multiple translation units into one complete model where the linking takes
place. The importURI mechanism is intrusive and inadequate for existing
languages.
E.g. you cannot write
import "com/acme/foo/MyClass.java"
in Java. You need to support a language specific method of deriving a URI
from model elements like a fully-qualified name com.acme.foo.MyClass, and
you need to support a root element in the model which is outside of any
given translation unit, something like a project or system.
- How do you deal with things like Javadoc comments? The XText reference
mentions hidden tokens supported by ANTLR 3, but it does not tell how to
access them via XText/Ecore application code.
- The model generated from the parser is usually only a subset of what you
need, e.g. you get a name for a Type but you also need its fully qualified
name; or for an expression, you get an operator and operands but you also
want the type of the expression or even its value (for constants).
So how do you enrich the model:
* Write your own Ecore model and tie the grammar to it explicitly?
* Insert non-generated operations into the EMF-generated interfaces and
implementation classes?
* Use Xtend?
- Usually, you need several passes over your parse tree, first to
establish semantic correctness and then to generate output. These passes
are either pre-link or post-link. How does that fit in with the automatic
linking in XText, in particular, how do you implement pre-link passes?
Regards,
Harald
|
|
|
Current Time: Sun Nov 24 03:07:54 GMT 2024
Powered by FUDForum. Page generated in 0.03454 seconds |
] 
Search
Help
Register
Login
Home
