Eclipse Community Forums: TMF (Xtext) » Inferred superclasses

Home » Modeling » TMF (Xtext) » Inferred superclasses

Sat, 05 February 2011 13:02

Eclipse User

Hi,

I'm using artificial parser rules like

CommonSuperType: // unused
SubTypeA | SubTypeB | SubTypeC;

to get a super type inferred in the resulting model. While CommonSuperType should be never
called, the generation still complains about being able to match input using multiple
alternatives. Is it safe to ignore such a warning for an unused rule? And if so, is there
a way to get rid of the warning?

Also, is there a technique to make a class a subclass of another class without creating
artificial rules/classes and without affecting the grammar, solely for shaping the result
model? Like in,

TypeA: 'foo' name=ID;
TypeB: 'bar' name=ID;

is there a way to get TypeB to extend TypeA in the model? The closest thing I found is

TypeB returns TypeA:
{TypeB} 'bar' name=ID;

But this also changes the type of references to TypeB to TypeA.

Thanks,
Greetings,
Ralf

Re: Inferred superclasses [message #652711 is a reply to message #652705]

Sat, 05 February 2011 14:37

Eclipse User

Hi,

make sure the warning is really caused by the CommonSuperTypeRule. My guess is that it is not.
A frequent cause for this warning are references via an ID where the parser cannot determine which type is actually to be referenced, the most obvious example being

...
Reference: 'reference' (ref1=[Type1] | ref2=[Type2]);
...

The model looks like this

reference ReferencedElement

But there is no syntactic indication whether an element of type Type1 or of Type2 was to be referenced.

In general you should NOT ignore this warning but find out where exactly in your grammar this ambiguity arises. Models might not be instantiated as you expect them.

Alex

Re: Inferred superclasses [message #652716 is a reply to message #652705]

Sat, 05 February 2011 15:15

Eclipse User

Hi Ralf,

I bet it's time to refactor to an imported metamodel ;-)

You could try to use the postprocessor but I'd not recommend that.

Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com

Am 05.02.11 19:02, schrieb Ralf Ebert:
> Hi,
>
> I'm using artificial parser rules like
>
> CommonSuperType: // unused
> SubTypeA | SubTypeB | SubTypeC;
>
> to get a super type inferred in the resulting model. While
> CommonSuperType should be never called, the generation still complains
> about being able to match input using multiple alternatives. Is it safe
> to ignore such a warning for an unused rule? And if so, is there a way
> to get rid of the warning?
>
> Also, is there a technique to make a class a subclass of another class
> without creating artificial rules/classes and without affecting the
> grammar, solely for shaping the result model? Like in,
>
> TypeA: 'foo' name=ID;
> TypeB: 'bar' name=ID;
>
> is there a way to get TypeB to extend TypeA in the model? The closest
> thing I found is
>
> TypeB returns TypeA:
> {TypeB} 'bar' name=ID;
>
> But this also changes the type of references to TypeB to TypeA.
>
> Thanks,
> Greetings,
> Ralf

Re: Inferred superclasses [message #652731 is a reply to message #652711]

Sat, 05 February 2011 17:35

Eclipse User

Hi Alexander,

> make sure the warning is really caused by the CommonSuperTypeRule. My guess is that it is
> not.

thanks for the tips; I double-checked the warning and it really is CommonSuperTypeRule and
the warning even happens without any reference to CommonSuperTypeRule or SubType at all. I
experimented a bit more and found that this happens only for a deeper hierarchy (class ->
supertype -> supertype). For example:

Entity:
'entity' name=ID;

TypeReference:
type=[Entity];

ScopeName:
TypedName;

TypedName:
Parameter | Property;

Parameter:
typeRef=TypeReference name=ID;

Property:
typeRef=TypeReference name=ID;

This causes a warning although all rules except Entity are unused. When I remove the
ScopeName rule or replace it with

ScopeName:
Parameter | Property

the warning goes away. In the real DSL there are more elements (ScopeName has additional
subclasses which aren't TypedName). Is such a structure allowed or am I missing something
here?

Greetings,

Ralf

--
- Ralf | http://www.ralfebert.de/

Re: Inferred superclasses [message #652732 is a reply to message #652716]

Sat, 05 February 2011 17:35

Eclipse User

Hi Sebastian,

> I bet it's time to refactor to an imported metamodel ;-)
> You could try to use the postprocessor but I'd not recommend that.

but except for the inheritance structure the inferred model is pretty ok; does managing
this manually instead of generating it has other advantages besides the inheritance which
would justify the additional effort to update the model everytime the grammar changes?

Also, I digged a bit deeper; the warning happens because I try to get a supertype for a
supertype, see my answer to Alexanders message for an example.

I also wondered, just out of curiosity, wouldn't it make sense to have some kind of syntax
to tell Xtext that some rule should extend some other rule, affecting only the model?

For example, I would like to refactor this:

TypedName:
Parameter | Property | Assignment;

Parameter:
typeRef=TypeReference name=ID;

Property:
typeRef=TypeReference name=ID;

Assignment:
typeRef=TypeReference name=ID '=' value=ProviderConstruction;

to something like this:

TypedName:
typeRef=TypeReference name=ID;

Parameter extends TypedName;

Property extends TypedName;

Assignment extends TypedName:
typeRef=TypeReference name=ID '=' value=ProviderConstruction;

Ralf

Re: Inferred superclasses [message #652738 is a reply to message #652732]

Sat, 05 February 2011 18:46

Eclipse User

Hi Ralf,

the transformation uses a somewhat limited algorithm to identify
uncalled rules. It does not work transitively. That explains your
observation.

Regarding your suggestion I doubt that the grammar is the right format
to define an ecore model thus I'd not introduce another concept for the
sake the generated metamodel.

Imported metamodels allow to define e.g. derived properties, super types
to factor common concepts into own types or define enum default values
explicitly.

Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com

Am 05.02.11 23:35, schrieb Ralf Ebert:
> Hi Sebastian,
>
>> I bet it's time to refactor to an imported metamodel ;-)
>> You could try to use the postprocessor but I'd not recommend that.
>
> but except for the inheritance structure the inferred model is pretty
> ok; does managing this manually instead of generating it has other
> advantages besides the inheritance which would justify the additional
> effort to update the model everytime the grammar changes?
>
> Also, I digged a bit deeper; the warning happens because I try to get a
> supertype for a supertype, see my answer to Alexanders message for an
> example.
>
> I also wondered, just out of curiosity, wouldn't it make sense to have
> some kind of syntax to tell Xtext that some rule should extend some
> other rule, affecting only the model?
>
> For example, I would like to refactor this:
>
> TypedName:
> Parameter | Property | Assignment;
>
> Parameter:
> typeRef=TypeReference name=ID;
>
> Property:
> typeRef=TypeReference name=ID;
>
> Assignment:
> typeRef=TypeReference name=ID '=' value=ProviderConstruction;
>
>
> to something like this:
>
> TypedName:
> typeRef=TypeReference name=ID;
>
> Parameter extends TypedName;
>
> Property extends TypedName;
>
> Assignment extends TypedName:
> typeRef=TypeReference name=ID '=' value=ProviderConstruction;
>
> Ralf

Re: Inferred superclasses [message #653089 is a reply to message #652738]

Tue, 08 February 2011 07:48

Eclipse User

Hi Sebastian,

> the transformation uses a somewhat limited algorithm to identify uncalled rules. It does
> not work transitively. That explains your observation.

the gray coloring of rule names in the Xtext editor seems to know more about uncalled
rules as far as I have observed - does it? Couldn't the same logic be used to not even
generate such artificial rules in the grammar so that the antlr validation doesn't
complain? For now, I really like the model being generated and so I'm ignoring the
warnings because that seems to be the best compromise, but I'd rather not have anything in
red font in the console... Is this considered a bug?

Greetings,
Ralf

Re: Inferred superclasses [message #653113 is a reply to message #652705]

Tue, 08 February 2011 08:55

Eclipse User

Hi,

> TypeA: 'foo' name=ID;
> TypeB: 'bar' name=ID;
>
> is there a way to get TypeB to extend TypeA in the model? The closest thing I found is
>
> TypeB returns TypeA:
> {TypeB} 'bar' name=ID;
>
> But this also changes the type of references to TypeB to TypeA.

d'oh - it's obvious - answering my own question, writing it like this does the trick:

TypeA:
('foo' name=ID) |
({TypeB} 'bar' name=ID)

- Ralf

Re: Inferred superclasses [message #653114 is a reply to message #653089]

Tue, 08 February 2011 09:15

Eclipse User

Hi Ralf,

it may be considered a bug but I doubt that we'll change this for indigo
since there are (unfortunately) clients out there that call this
unreachable rules reflectively.

Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com

Am 08.02.11 13:48, schrieb Ralf Ebert:
> Hi Sebastian,
>
>> the transformation uses a somewhat limited algorithm to identify
>> uncalled rules. It does
>> not work transitively. That explains your observation.
>
> the gray coloring of rule names in the Xtext editor seems to know more
> about uncalled rules as far as I have observed - does it? Couldn't the
> same logic be used to not even generate such artificial rules in the
> grammar so that the antlr validation doesn't complain? For now, I really
> like the model being generated and so I'm ignoring the warnings because
> that seems to be the best compromise, but I'd rather not have anything
> in red font in the console... Is this considered a bug?
>
> Greetings,
> Ralf

Previous Topic:	Serialization of EFloat
Next Topic:	How to readline grammars

Goto Forum:

-=] Back to Top [=-

Current Time: Tue Jul 15 17:01:22 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter