[news.eclipse.technology.ldt] Re: Beyond textual represenations...

[Ed Merks <merks@xxxxxxxxxx>]

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