[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
|
[news.eclipse.technology.ldt] Re: Beyond textual represenations...
|
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@xxxxxxxxxxxxxxxxxx
>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