|
|
|
Re: Model transformation: how to force the order of output elements based on the order of input elem [message #1028611 is a reply to message #1022768] |
Thu, 28 March 2013 13:46 |
Joost van Pinxten Messages: 51 Registered: November 2012 |
Member |
|
|
Thanks to the RulePriorityActivationComparator (RPAC) I'm now able to specify:
1. rule ordering by priority
2. activation ordering (with same rule type) using the original order of containment (see also https://bugs.eclipse.org/bugs/show_bug.cgi?id=403825)
Unfortunately, this is not yet enough for my use case; expression trees do not have a 'static' priority, as they can be nested arbitrarily. Such nesting occurs if you metamodel allows some kind of containment cycles (as is quite common with nested expressions).
Say that I have an abstract Primary element, which specializes into Expression and Literal. Expression specializes again into multiple types: e.g. a BinaryExpression (like add, multiply, etc). Any BinaryExpression has a left and right hand side, which is a containment reference to a Primary (e.g. either a Literal or an Expression).
Based on this, I would like to be able to extend/annotate/label an expression pattern with a 'depth' or 'transformationOrder'. By making all Expression rules the same priority in the RPAC, it would be possible to arrange the activations for the expression containment tree such that the container elements are created before the contained elements are created.
How can I make something like this possible? I've tried the following:
pattern depth(primary : Primary, depth) = {
Literal(primary);
depth == 1;
// Always a leaf element
} or {
BinaryExpression(primary);
BinaryExpression.left(primary, left);
BinaryExpression.right(primary, right);
find primaryExpressionDepth(left, ldepth);
find primaryExpressionDepth(right, rdepth);
// check(depth == Math::max(ldepth, rdepth) + 1); // No positive inference
// depth == Math::max(ldepth, rdepth) + 1; // Invalid syntax
}
Is it possible to write such a bottom-up (or top-down) labeling mechanism with the currently available pattern language?
If not, then I'll probably resort to writing a custom solution by modifying the comparison mechanism of the RPAC.
P.S. I'm aware the the RPAC will probably get refactored soon.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.01682 seconds