[henshin-dev] Nested Rule semantics

[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