Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [incquery-dev] xcore & incquery integration

Hi,

-----incquery-dev-bounces@xxxxxxxxxxx ezt írta: -----
-The derived feature spec: the current language of Xcore does not allow to write something like 'derived Int numberOfBooks spec library.numberOfBooksOfWriter'. The problem is with the spec keyword. If I create an other language (for example 'IncQueryXcore' which extends the Xcore language) then I can create a new language element XIncQueryDerivedFeature, which has a definition like:

XIncQueryDerivedFeature:
    {XIncQueryDerivedFeature}
    'incquery-derived'
    type=XGenericType multiplicity=XMultiplicity?
    name=ID
    'spec' (pattern=[patternLanguage::Pattern])
    (';')?
;

Here, note that the keyword is 'incquery-derived', not 'derived'. Using the latter keyword would cause that the antlr generator throws an error that the given language is not LL(*), because an XStructuralFeature (from Xcore) can also start with the 'derived' keyword. 
So if we used there 'derived', that would be a keyword clash between the two separate rules XIncQueryDerivedFeature and XStructuralFeature. 
But do they absolutely need to be two separate rules? Can't we just change the rule XStructuralFeature by adding an _optional_ tail looking like this: 
('spec' (pattern=[patternLanguage::Pattern]))?
And then there would be only XStructuralFeatures, some of which would have a "spec" clause. So it seems to me that it is possible to keep the simpler syntax.
Of course, this solution may mean that we would have to add a validator rule to enforce that if the feature has a spec, then it must be marked as derived as well. Then again, incquery-based derived features will require a buttload of other validators as well.

Disclaimer: I am far from being an Xtext expert, so forgive me if I have said something stupid :)

Cheers
Gábor


Back to the top