[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [incquery-dev] incquery & mps
|
Hi!
I have started to port the incquery language & engine into MPS. The
language is already available in MPS
Cool!
and now I would like to make use of
the real underlying engine too.
In order to do that, I would like to collect the steps and some ideas
about how to do that.
* I have located the source of the information in MPS which is needed
for the incremental updates. Something similar to the base index should
be built on top of this layer.
Yes.
The navigation helper API is not directly necessary for the query engine;
the query engine needs a "context" as its interface to the outside world.
org.eclipse.incquery.runtime.matchers.IPatternMatcherContext is for
providing metamodel info, and its extension IPatternMatcherRuntimeContext
also provides instance model info. EMFPatternMatcherContext implements the
former with Ecore reflection and EMFPatternMatcherRuntimeContext implements
the latter using IQBase. You will need to somehow implement these two
interfaces (maybe using the same class) over MPS.
I apologize in advance for the lack of documentation on these two
interfaces. Feel free to ask if anything is unclear.
Some notes on terminology: for each node type, we assume that there is a
unary relation (i.e. set) of instances (including instances of subtypes).
For each edge type (such as EStructuralFeatures), there is a binary relation
of sources and targets. This is for modeling platforms such as EMF where
edge instances themselves do not manifest as objects. If the edge instance
itself is identifiable as an object, it is a "ternary"; you need to be able
to enumerate all such edge instances (for a type and subtypes), and there
are other method to access the source and the target afterwards.
Does the structure of MPS models fit into this? If you think any of this is
incompatible with MPS, please tell. Maybe we need to change / adapt /
generalize these interfaces. There are at least two other ongoing projects
(Incquery-D and Mondix) where we are planning to provide alternative
implementations these interfaces, and at least one more project where we may
want to use it (local search), so this might be a good time to refactor them
into something that fits all these needs.
* Which is the entirely EMF and Xtext independent part of IncQuery? I
guess this is only true about the RETE network implementation.
* org.eclipse.incquery.runtime.matchers --> truly independent
* org.eclipse.incquery.runtime.base.itc --> truly independent
* org.eclipse.incquery.runtime.rete.recipes --> only depends on EMF because
it uses Xcore-based data representation; but the instance model is not
assumed to be EMF, so this shouldn't be a problem.
* org.eclipse.incquery.runtime.rete --> depends on recipes, so has the same
EMF dependency. Mistakenly declares a dependency on incquery.base, but does
not really depend on it - I think I am going to remove this right away.
* org.eclipse.incquery.patternlanguage --> likewise makes no assumptions
that the instance model is EMF... but you are unlikely to need this
Unfortunately, org.eclipse.incquery.runtime is entirely EMF-specific at the
moment. So you need to come up with your own MPS-IncQuery substitutes for
IncQueryEngine, IQuerySpecification, etc. I do not know right now what we
can generalize here.
* The code generators should generate the PSystem code out of the MPS
instance model, right?
PSystem is a description of the query. So it should not be generated from
the instance model on which you want to match patterns, but from the pattern
model that is expressed using the language extension you have built in MPS.
(Sorry if you meant this by "instance model").
If you want this language extension be used for the "interpretative"
scenario as well (just like query explorer with eiq files in the workspace),
then you should be able to generate an in-memory PSystem model, not just
Java code that constructs the PSystem model. If you want to generate the
code from the in-memory PSystem model, you should take a look at
PatternQuerySpecificationClassInferrer.inferBodies().
* I have extended the base language of MPS with some constructs which
can be used to utilize the patterns written in a pattern model.
This is basically an extension for the Java language in MPS with some
additional statements. In MPS (within MPS) the user will never ever
interact with the generated code.
Sounds reasonable.
Could you perhaps show some "code" samples?
Basically my aim with this e-mail is to start some discussion about the
next steps of this integration. If you are interested, I could do a
quick overview sometimes about the language and some really brief intro
to MPS.
Sure, we are absolutely interested!
Cheers,
Gaben
