Re: [incquery-dev] xcore & incquery integration

[Istvan Rath <rath@xxxxxxxxxx>]

I think it would be even better to change the file extension to something new, e.g. ".xcoreiq"

Would this solve the problem?

--

Istvan RATH, PhD

Research fellow
Budapest University of Technology and Economics

Fault Tolerant Systems Research Group

On Monday, June 3, 2013 at 10:07 AM, Tamas Szabo wrote:

Yes, that would be the best way to do it, but then comes the problem with the "same file extension - different editor and xtext artifacts" issue:
Both xcore and the modified language (with the incquery interation) would have an own language (the incquery related one extends xcore), mwe2 workflow to generate the artifacts, etc.
The explicitly defined metamodel would not be an issue, because I can define an other ecore metamodel for the new language with just adding the additional (new) model elements and referencing the Xcore.ecore.

On Friday, May 31, 2013 at 11:34 AM, Tamas Szabo wrote:

The idea is nice, but I am not really allowed to modify the xcore code/language.

But can't we do it in a non-invasive way, i.e. instead of modifying Xcore, creating a new DSL that extends Xcore and overrides this particular rule according to Gaben's suggestion?

I know that there is some issue with Xcore having a manually constructed metamodel, but if you could elaborate more on this, then perhaps we could discuss the proposed solution better.

Istvan

--

Istvan RATH, PhD

Research fellow
Budapest University of Technology and Economics

Fault Tolerant Systems Research Group

 

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

_______________________________________________

incquery-dev mailing list

incquery-dev@xxxxxxxxxxx

http://dev.eclipse.org/mailman/listinfo/incquery-dev