Bug 327853

Comment 1 Moritz Eysholdt 2015-06-05 03:44:16 EDT

yup, I ran into this too.

Comment 2 Sebastian Zarnekow 2015-06-05 04:06:20 EDT

Unfortunately it doesn't play well with generated EPackages

Comment 3 Moritz Eysholdt 2015-06-05 04:20:11 EDT

We'd need to agree on how to convert a grammar expression (several tokens) into a literal value (string). That's all, isn't it?

E.g. 

----- grammar ------
enum Foo:
  lit1=("a" "b") | lit2=("c" "d"?);
--------------------

could become

------ Ecore -------
enum Foo {
  literal lit1 value="a b"
  literal lit2 value="c"
}
--------------------

In this example I joined the keywords of the shortest syntactical path with a single space.

I think that strategy is similar to our already-exisitng scenario in which we need to decide for a literal value: When having multiple values per literal.

----
enum Foo:
	lit="value" | lit2="lit2v1" | lit2="lit2v2";
----

Here, we take the value of the fist occurrence of the literal ("lit2v1" in this example).

Comment 4 Sebastian Zarnekow 2015-06-05 04:44:36 EDT

I think data type rules are a nice alternative to a semi-magic concatenation of strings to a literal value, e.g. in your proposal it's still keyword only. The next request is probably to allow alternatives, terminal rule calls etc. Exchanging one limitation with rather clear semantics for another one with involving semantics but still obvious limitations ... probably not time well spent, I guess.

Comment 5 Moritz Eysholdt 2015-06-05 04:51:15 EDT

We could allow it for imported Ecore models. Then there would be no magic because the literal's value would be explicitly specified in the Ecore model. 

The advantage would be that as a developer I would not need to have and maintain a value converter for that enum.

Comment 6 Sebastian Zarnekow 2015-06-05 05:26:24 EDT

(In reply to Moritz Eysholdt from comment #5)
> We could allow it for imported Ecore models. Then there would be no magic
> because the literal's value would be explicitly specified in the Ecore
> model. 
> 
> The advantage would be that as a developer I would not need to have and
> maintain a value converter for that enum.

Yes, that'd be nice.

Comment 7 Knut Wannheden 2015-06-05 05:45:02 EDT

Soon I will have to start reporting some issues again. I don't have many unresolved ones left :-)

Comment 8 Knut Wannheden 2015-06-05 15:58:07 EDT

An alternative syntax if we still only want to allow the alternatives operator, keywords, and the assignment operator would be:

enum Foo:
  lit1="a" "b" | lit2="c" | lit2="c" "d";

Then we could continue using the current strategy for generated models.

It may look a bit awkward, but I don't think it is too bad, because I would sometimes do the same when I assign a boolean attribute based on two keywords (e.g. "(c?='c' 'd')?").

But regardless of the concrete syntax for this, I think that if we find an easy (albeit limited) solution for how to derive the literal values for a generated model that would be nice. Generated models are very useful for prototyping (and bootstrapping to some extent) and I think the users are well aware of the limitations of the model inference and wouldn't mind if they can't fully control this aspect of it.