#1 Extent contexts
The following feature request was submitted via email:
Would there be a problem with the context of a term being an
AbstractVar, or even an Expression?
One of the problems I'm having is that for a transformation
T : a, b, c -> d
the derived delta transformation DT has several extents for each
source extent from T, namely an old, a new and a delta extent:
DT : -a, +a, da, -b, +b, db, -c, +c, dc -> ...
I would like to be able to write a single pattern to extract information
from a number of these extents, and it would be handy to be able to
have the extent as an input variable to the pattern, something like:
PATTERN addedObject(e, o, t)
FORALL NewObject@e d
WHERE d.id.newObject = o
AND d.type = t
;
so calls to this pattern would search for objects in different extents,
e.g.:
addedObject(da, o, t)
addedObject(db, o, t)
addedObject(dc, o, t)
however this requires the context of the MofInstance to point to e,
which is a PatternVar.
Of course it may be possible to simply cut-and-paste the body of the
pattern into places where it is called, however some patterns are a little
to big for that to be desirable. Alternatively, we can generate multiple
copies of the pattern definition, one for each extent, but it would be
nicer to just have one.
If the semantics of MofInstance (or any Term with a context) are that
the extent used is whatever the context variable is bound to, then
could that variable (theoretically) be any variable?
The only problem I can see is that this would make static analysis of
extent usage intractable, but if no static analysis of extent usage is
performed, then are there any other potential problems?