Community
Participate
Working Groups
It would be nice with the possibility to define an enum rule where a single literal can consist of multiple tokens. The current workaround is to define the rule as a datatype rule with a value converter.
yup, I ran into this too.
Unfortunately it doesn't play well with generated EPackages
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).
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.
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.
(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.
Soon I will have to start reporting some issues again. I don't have many unresolved ones left :-)
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.
