The relative presentation slide is located at openArchitectureWare.org.
Part 2 of the notes is located at http://www.frankdu.com/weblog/archives/52
Below are my reading notes for Textual DSLs and text modeling in eclipse. I haven’t finished the ppt slides. Therefore, this is only part one.
1. EMF servers as the foundation. It provides Ecore Metamodel and framework tools like:
- editing
- transactions
- validation
- query
- distribution/persistence
2. GMF is used for building custom graphical editors based on EMF meta models. It is industry-proven technology. Based on GEF.
3. TMF is used for building custom textual editors. It is in incubation phase. There are two implementations: Xtext and TCS.
4. M2M (Model-to-Model) delivers an extensible framework for m2m transformation languages. ATL is M2M language from INRIA. QVT is an implementation.
5. M2T (Model-to-Text) focuses on transforming models into text (code generation, model serialization). For example, you may want to convert in-memory models into xml files for persistence/transportation purposes. You may want to use a parser to convert xml files back to models. There are 2 so-called frameworks:
- JET is code generation tools that are used by EMF
- Xpand is code generation tools that are part of M2T releases.
6. Xtext is originally from openArchitectureWare.com. It’s a good integration with eclipse. The oAW uses EMF as a basis, bases graphical editors on GMF, and all tooling are based on eclipse. Since Xtext has become part of eclipse TMF, there are two versions of Xtext: oAW Xtext, and TMF Xtext. The former is relatively mature. The latter is under active development, and expected to be first released sometime this year, namely in 2009.
7. DSL is a focused, processable language for addressing specific concerns in a specific domain. It is targeted to be a simple tool for a relatively complex domain. Therefore, in most cases, DSLs are human-readable to domain experts without any training. The popular DSL examples are SQL and Excel.
8. DSLs can be classified in many ways:
- configuration vs. customization
- internal vs. external
- graphical vs. textual
9. Xtext is a so-called framework tool for building external textual customization DSLs.
10. Is it possible to edit same model with both textual and graphical editing interfaces?
It might be possible. Consider one of the following: a. Visualize a subset of the model, using graphvis or prefuse. But it is typically read-only. b. Use different perspectives. Some of them use graphcial editor. It requires cross references between textual and graphical models). c. Edit the same model textually and graphically. Textual format is used as the serialization format from the graphical model. It requires writability and sync of both models!
11. Typically textual DSLs leverage one of many parser generators (ANTLR, Java CC, Lex/yacc). They help to generate a parser based on grammar definition. Consequencely, a parser tries to match text, and try to create a parse tree.
12. Typically, textual DSLs are transformed into an Abstract Syntax Tree (AST). It is ofen a binary tree. For exampe, the AST for 1 + 2*3:
Literal[1] AddExpression ( Literal[2] MultiplyExpression Literal[3])
Literal, AddExpression, and MultiplyExpression are binary nodes.
13. The AST can be taken as a model. But textual DSLs are written without careness of the AST. They can even be against AST.
14. Challenges in Xtext DSL implementation:
- Writting a parser is non-trivial.
- A parser generator makes life easier, but still not one for all.
- A parser generator only creates a matcher and/or a simplistic AST. You still need to further transform the model to easily processable form, and create an editor with syntax highlighting, code completion, etc.
Xtext is designed to ease unbearable burden of life like that.
15. Xtext is based on an EBNF grammar (what’s that? Why will it make a difference?). Xtext will generate:
- ANTLR-based parser
- EMF-based metamodel
- Eclipse editor with or extensible for: syntax highlighting, code completion, code folding, constraint checking, and so on.
16. Different Kinds of Xtext Rules:
- Type Rule
- String Rule
- Enum Rule
- Native Rule
17. Built-in Lexer Types in Xtext:
- ID
- STRING
- INT
- Comments ( Single line and multiple lines)
- Whitespace
The content of those rules is not transformed into the meta model. (How it matters?)
18. Built-in Reference Types in Xtext:
- Reference
- File Reference/Import
19. Abstract Type Rules are implicitly declared with a collection of OR-ed alternatives: R1 | R2 | R3. They will be mapped to abstract metaclass. The alternatives will become subclass. The common properties will be lifted into abstract superclass.
20. String Rules are declared in the format: String [rule_name]: [rule_definition];
21. Enum Rule is mapped to Enum in metamodel. Its format: Enum [rule_name]: [token_name="string"]+;
22. Native Rule. Example:
Native SL_COMMENT:
“‘#’ ~(‘n’|'r’)* ‘r’? ‘n’”;
Term:
1. EMF – Eclipse Modeling Framework
2. GMF – Graphical Modeling Framework
3. GEF – Graphical Editing Framework
4. TMF – Textual Modeling Framework
5. DSL – Domain Specific Langauge
6. JET – Jave Emitter Templates
7. AST – Abstract Syntax Tree
Continue to read: Part 2 of the notes is located at http://www.frankdu.com/weblog/archives/52
