| Re: [henshin-dev] Nested Rule semantics |
Hi Felix,
I am not sure that I got the point.
The kernel rule (the rule which wraps others; depends on the viewpoint:a
rule might be a multi rule and a kernel rule) always partially
predefines the match for its multi rules. If the partial match then can
be completed, a match of a multi rule has been found.
This is how it works and how it is supposed to be, isn't it?
The user is furthermore free to predefine the match of an outermost
kernel rule as well via parameters. So whats the point?
Regarding the style: Sometimes it is more adequate to use deep nesting
of multi rules, sometimes a more flattened variant shall be preferred
e.g. if reuse of (multi) rules is desired. We should not restricts that,
in my opinion.
Regards,
Stefan
Am 20.03.2012 17:06, schrieb Riegerf@xxxxxxxxxxxxxxxxxxxxxxx:
> I was wondering about the nested Rule semantics and the execution of
> nested Rules. Nested Rules seem to have forall-semantics from the 1st
> nesting level onwards, which seems to work as intended, but might not
> be what we really want to have.
> If the outermost Rule matches, this is counted as a match,
> irrespective of whether the nested Rules match. This leads to more
> matches than one would expect, most of which are of little value to
> the Rule developer. The biggest problem is that the engine starts
> matching anywhere on the graph, so the first match will most likely
> not be the "best" (i.e. intended) match, but some random match which
> happens to match the outermost (was: kernel) rule, even if much better
> (i.e. deeper) matches are available.
>
> In the current implementation, using deeply nested rules in
> Transformation Units could be somewhat of a challenge for our users.
>
> There seem to be several approaches to solving this problem. This also
> depends on the style we want to encourage the user to use, i.e. mainly
> relying on very flat rule trees or fully embracing the possibility to
> deeply nest rules. One possible approach might be to sort the matches
> before returning them, so the "best" match will always be returned
> first ("best" would need to be defined, however. Deepest match? Most
> Rules matched? etc.), but this might have a negative impact on
> performance. Another possibility is to change the semantics to require
> at least 1 match of a nested rule ("forall-but-at-least-one").
> However, this will make the language less expressive and might even
> break compatibility with existing code.
>
> Felix
>
> _______________________________________________
> henshin-dev mailing list
> henshin-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/henshin-dev
Attachment:
signature.asc
Description: OpenPGP digital signature