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 Jan,

I hope you're well again.

On Feb 20, 2009, at 11:06 AM, Jan Köhnlein wrote:

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...

Defining empty grammars is currently only useful in order to change the hidden tokens.
I think it won't be that important in practice, but I also think we should allow it as it's not a problem.



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.

Good point. We don't have a super call yet. But I think your proposed approach would be nicer (because more general) than an explicit entry rule construct.


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?

This item just means that we want to disallow assigning of e.g. Actions (like in  "Foo : foo={FooBar}") on syntax level rather than via constraints.
Because than other infrastructre components which rely on the grammar get this information as well. For instance, code completion won't propose Actions in assignments anymore.

This can be done similar to how Sebastian already limited the number of AbstractElements available in TokenRules.

Something like this would do it:

Assignment returns Assignment:
   feature=ID operator=('+='|'='|'?=') ^terminal=Assignable; 

Assignable returns AbstractElement :
   RuleCall | Keyword | CrossReference






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?

Yes the grammar language is not documented at all. We'll have to do that as well.

With the UntilToken you can write things like string literals or mutlline comments in a convenient and readable way:

Token StringLiteral : '"' -> '"';

Where (-> '"') says consume everything until ".




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?

We wanted to make qualified names mandatory. So if you have declared an alias on the meta model declaration, you need to use it when referencing types.

The other thing we talked about was to allow only one "generate" and any number of "import" declarations per name space (i.e. alias).
The scoping first would look into all imported packages and if it cannot find the resp. type it assumes that it should be created in the 'generate' package.
This would mean that in:

grammar Foo

import ".....ecore"
generate foo "bar"

Eclass : .....

a new class "Eclass" would be created in package foo, because I (accidentally) spelled it (Eclass not EClass).
Mmmmhh... users will be surpised by that. Maybe we shouldn't allow generated and imported EPackages sharing the same alias?

Sven




-- 
Sven Efftinge

Phone: +49 431 5606335
Fax     :  +49 431 5606339
Mobile: +49 175 5274726

itemis AG
Schauenburgerstraße 116
24118 Kiel
Germany

Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek
Aufsichtsrat: Dr. Burkhard Igel(Vors.), Stephan Grollmann, Michael Neuhaus

Back to the top