Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [xtext-dev] Discussion: Syntax of Xtext-Files 
Hi,
thanks to the comprehensive summary. I agree to most of these points, but some questions remain. As I am not sure whether we can manage a tree shaped discussion with bugzilla, I try to clarify things here before posting. 

Here are my comments (inline, sorry)


3. One language per file
We want to stay with the one language per file paradigm.
With respect to 1) this should be one *grammar* per file, shouldn't it ;-) 


6. Allow zero rules per grammar
We should allow grammars without any new rule. This enables clients to mix several languages and actually not define any new rule. This will require a way to mark the entry rule. We decided to allow defining the 'main' rule.
AFAIU, if I mix several grammars without defining a new rule, only the rules from the grammar containing the entry rule will be reached. Does that make sense? I think I missed the point here... 

We could also consider to mark the entry rule by overriding it:

  grammar X with Y,Z
  Entry: Z::Entry;
or whatever the syntax to call overridden rules should be. Appears more suggestive to me, as we don't introduce a new concept while being just a little bit more verbose.
If we stick to your solution, I'd prefer to call the keyword "entry(rule)" instead of "main". Looks more grammar-like and less Java- like to me. 


9. Assignments
We allow any AbstractTerminal (type AbstractElement) to be assigned on the concrete syntax level. However, most of the services (linker, transformer etc) can only deal with a smaller subset of AbstractElements. We think about restricting the tokens on concreate syntax level to assignable elements (nested Alternatives, CrossReferences, Keywords, calls to datatype rules and terminal rules without any cardinality defined) but stay with AbstractElement on abstract syntax level.
Sorry I don't understand that. I guess "concrete syntax level" means node model, doesn't it? 
1) What does "assign on the concrete syntax level" mean?
2) Is "assignable" equivalent to being the right hand side of an Xtext Assignment? 3) Which AbstractElements cannot be dealt with by the linker, transformer? 
4) How do we restrict things on concrete syntax level?


11. Rename UpToToken to UntilToken
UpTo clashes with the intuitive understanding of 'up to' as it is a construct to describe loops in a few languages. 

Can you give an example / add documentation for the UntilToken?


13. Metamodel declarations and aliases
The current implementation of the XtextLinker is very .. tolerant. It is not mandatory to use defined aliases when you refer to classifiers of a specific EPackage. 
For example this would be perfectly ok:

generate bar 'http://www.eclipse.org/bar/2009' as bar
import 'http://www.eclipse.org/emf/2002' as ecore

Foo returns EString: 'foo' STRING;
Zonk returns ZonkType: attrib=Foo;
It is not required to qualify the reference to EString. Linker and transformer will find a datatype EString in one of the metamodels and use this one. In the other case a new type will be created in EPackage bar. We think this behavior is errorprone. Types should be references by their qualified (aliased) name, if an alias has been defined. 

generate bar 'http://www.eclipse.org/bar/2009' as bar
import 'http://www.eclipse.org/emf/2002' as ecore

Foo returns ecore::EString: 'foo' STRING;
Zonk returns bar::ZonkType: attrib=Foo;
However, if the alias is omitted, the current "best guess" algorithm will be used. 

Agreed. So what are we going to do. Create a warning?

Cheers
Jan



--
Dr. Jan Köhnlein
Senior Software Architekt

Telefon: +49 (0) 431 / 5606-337
Mobile: +49 (0) 151 / 17396687
Telefax: +49 (0) 431 / 5606-339

http://www.itemis.de
jan.koehnlein@xxxxxxxxx

itemis AG
Niederlassung Kiel
Schauenburgerstr. 116
24118 Kiel
http://www.itemis.de/

Rechtlicher Hinweis:
Registergericht: Amtsgericht Dortmund HRB 20621
Sitz der Gesellschaft: Lünen
Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vorsitzender), Stephan Grollmann, Michael Neuhaus

Back to the top