Here is what the article states:
- Users can freely define new languages which are fully integrated with each other.
- The primary source of information is a persistent abstract representation.
- Language designers define a DSL in three main parts: schema, editor(s), and generator(s).
- Language users manipulate a DSL through a projectional editor.
- A language workbench can persist incomplete or contradictory information in its abstract representation.
I think this point is an implementation detail:
- The primary source of information is a persistent abstract representation.
Why should the source be the AST? What is the benefit from a user's perspective. Shouldn't this be transparent anyway?
I don't want to "feel" like editing the AST, because that's why there are concrete syntaxes, they are closer to what I am thinking about.
It's possible to store the information in a concrete syntax (e.g. a Java File) but view and edit it using other representations (e.g. outline views, call hierarchies,refactoring actions etc.).
Eclipse JDT for example has the complete AST in memory to help the user while editing and exploring the code. They don't need to store the Java files in an XML or a database. So if you know how to define a projection on an AST (like Intentional does), you could do this against a temporary, in-memory AST as well.
IMHO storing programs using the abstract form is a bad idea.
UML-Tool users know why:
You can't use existing text editing tools (diff, editors, etc.). You are always bound to the "Language Workbench". And you have to come up with your own version control system.
People who've used graphical DSL-frameworks like GMF know that in addition it is much harder to migrate your code/model to newer versions of your DSL, because you've to do that using the syntax of the stored AST (ugly XML at it's best). (Of course, Intentional may have developed a special "migration tool" for this as well ;-))
So I 'ld like to change the requirements like so:
- Users can freely define new languages which are fully integrated with each other.
- Language designers define a DSL in the following parts: abstract syntax, concrete syntax(s), tooling (editor(s), view(s), wizard(s)), and generator(s) or interpreter(s).
- Language users can manipulate a DSL using the defined tooling, which can be different editors, actions or wizards.
- A language workbench can persist incomplete or contradictory information.
