Dear Ed.
In
our daily work this problem doesn?t exist. I?ll answer your
questions:
Background:
Our
approach creates a XML-based model for each arbitrary language. Thereby, all
language specific elements (including declarations, inheritance constructs,
etc.) are expressed within a specific XML node structure. Hereby, it is
important to mention that the language constructs and features are completely
independent of the XML Schema language features (e.g., single inheritance,
reference, etc.), because XML Schema defines only the structure of a valid
language document and not the semantic of each XML model node. This includes,
for example, that the language can comprise special elements for multiple
inheritance and typed pointers, without the necessity to say something about the
subsequent implementation/realisation of the language (e.g., the usage of an
interpreter, language mapping, etc.).
Why
do we use this approach?
1. In
the case of existing languages (such as Java, C++,? plain-text views), this
XML-model creation process can be easily handled via the involvement of existing
grammars, which can be used to get a XML-based model version (via the traversal
of the AST). This goes along with Badros?s research (JavaML) work.
2.
Additionally, the EMF philosophy is easily applicable. Using the schema file of
this language, an Ecore model can be created which can be used (in conjunction
with the genmodel), e.g., to create a java code based interpreter
implementation. Furthermore, with the help of OMG approaches (UML, Action
Semantic, etc.) this process can be refined. In my opinion, Philipp Kutter?s
work already leverages these things.
3.
Our current work addresses the creation of a platform-independent service
language layer (sll). On the one hand, we use its XML based model for a direct
execution via an interpreter. And on the other hand, we want to convert a PIM
instance to a specific PSM (e.g., a Java Axis based implementation in order to
execute send_sync statements) and want to perform inter-model transformations
(e.g., adding a certain piece of functionality). What we need is a general
approach that allows all these aspects.
In my
opinion, it would be great when the LDT can provide support for any arbitrary
language (including constructs for typed references, multiple inheritance, etc.,
when needed) without giving the restriction that the generated code have to be
Java. If I?m right, then EMF exactly addresses the aforementioned aspects (code
generation, model-to-model generation, etc.) and should be extended where needed
(view support: plain-text, graphical, etc.) within this
project.
Regards,
Christian
Christian,
XML
Schema can't express multiple inheritance, so I wonder how the proposed
approach works for languages that need to use multiple inheritance in their
model. In addition, XML Schema can't express typed references/pointers
and has no standard way of dealing with cross file references/pointers.
What's your thinking on how to deal with that?
Christian Reichel
wrote:
My team of the Flexible XML-based Languages (FXL) Project uses two
principles in order to deal with multiple languages (DSLs):
1. The representation principle: All plain-text, graphical, etc.
representations of an arbitrary programming language are converted to a
XML-based, language-specific model. For example, in the context of Java this
means that we've created an XML based model for Java (called xJava), whereby
the traditional Java-syntax is handled like any arbitrary java view
(MyJava1, MyJava2, etc.). Thereby, for all views the view-to-model and
model-to-view transformations have to be specified, which can be, for
example, based on ANTLR and XSLT.
2. The transformation principle: Which covers inter-model and model-to-model
transformations, e.g., based on XSLT. It provides support for various issues
such as software generators, aspect weaving, technology mapping, etc.
Regarding this discussion about ASTs, EMF, JDT, etc. :
1. The hierarchical structure of an AST allows us to use XML for persistence
purposes and to define a schema (xsd) which holds the model information.
2. When a XML Schema is definded for each XML-persisted language, the next
step from an XSD model to MOF/EMOF (Ecore) isn't really far. A specific
schema for each language allows us to deal with the highly dynamic field of
DSLs, whereby consolidation with the help of a general model, e.g., based on
XMI MOF/EMOF currently covers only the aspects within an object-oriented
world.
3. Additionally, model transformations can be implemented with the help of
EMF oriented languages (ATL, etc.) as well as based on XML standards such as
XSLT, xQuery, etc. This provides a high grade of flexibility and an enormous
tool support.
In my opinion, a really useful LDT has to deal with a bunch of approaches in
order to create a powerful toolkit. This definitely includes concepts of
MDSD/MDA, AOP, existing frameworks (EMF,...), traditional compiler
principles, XML standards and so on. Therefore, it is defninitely useful to
bring the experts of all fields together. I hope that the goal of LDT is to
provide a general approach which is secondary applicable in the context of
eclipse (JDT, etc.). I'm not sure, weather these aspects are on the agenda
or not.
Regards,
Christian Reichel
"Guillaume Pothier" <gpothier@xxxxxxxxx> wrote in message
news:d1fm9d$93j$1@xxxxxxxxxxxxxxx...
I am really glad that the LDT project has been created.
Many of the posts to this newsgroup discuss ASTs and parsers, assuming
that a programming language's primary representation will always be its
textual form.
As far as I am concerned, I anticipate the day when the primary from of a
programming language is its AST, or even better, Abstract Syntax Graph.
Given the currently available computing power of the machines used by
developpers today, I think it is no luxury to start thinking of replacing
the traditional bunch of source files stored in a hierarchical filesystem
by a graph of objects backed by some database system.
There are a few obvious benefits to do so, even in the simple case of
Java-only developments:
- No more source code formatting hell and obnoxious merge conflicts caused
by formatting differences between developpers.
- Elimination of the parsing step from the compilation
I think the first thing LDT should provide is a new storage metaphor based
on ASTs (or ASGs). Of course, this representation issue does not solve all
the problems LDT proposes to deal with, but it would be a great foundation
for implementing new language support.
Regards,
Guillaume Pothier
|