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

[Chris Daly <cjdaly@xxxxxxxxxx>]

I read the subject line and thought you were going to make a different 
point:  that you might want to specify a language with a number of 
different notational forms.  You might want,

- textual notation (like Java, C, etc)
- diagrammatic notation (like UML)
- form-based notation (like the forms you see when you edit your plugin.xml)

You might want some kind of blend of the notations used in your tooling. 
And you might want a common object model behind all of the notations.

I think this is a fascinating area to work in, *BUT* way beyond what LDT 
should try to tackle at the beginning.  I'd hope that LDT can start with 
a focus on textual languages, but at the same time I'll be keeping an 
eye on the newly proposed GMF (Graphical Modeling Framework) project 
because that's where the good diagrammatic language tooling is likely to 
come from.  Maybe there will be a way to unify LDT and GMF at some point 
in the future....


Chris


Guillaume Pothier wrote:
> 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