[henshin-dev] Behaviour of INOUT Parameters and ParameterMappings

[Benjamin Heidelmeier <heidelme@xxxxxxxxxxxxxxxxxxxxxxx>]

Dear Henshin devs,
together with Gabriele Taentzer I talked about Parameters as I am 
currently writing a test suite. Two questions popped up during this 
conversation which we want to discuss with you before proposing merge 
requests.

1) Which is the desired behaviour of the INOUT parameter?

- IN && OUT: parameter needs to be set externally before the unit 
application AND can be set/changed during the unit application AND can 
be read once the unit has been applied.
- IN || OUT: behaves like IN OR behaves like OUT.
- (IN || !IN) && (OUT || !OUT): can behave like IN AND can behave like 
OUT. It's also possible that it's never set. This is similar to the 
current behaviour of UNKNOWN.

The first option (IN && OUT) seems to be the current behaviour for 
rules and is also documented like this in the Wiki. Which behaviour 
would you prefer?

2) Which parameter mappings should be possible?

Currently the only statements about possible parameter mappings are to 
be found in HenshinValidator.java. This is the class responsible for 
building error markers in Eclipse UI for Henshin.
The Javadoc comments of the according validator methods state the 
following (complete list):
- If the source of a parameter mapping is an IN parameter contained in 
a unit, the target parameter has to be of the kinds IN, INOUT or 
UNKNOWN.
- If the source of a parameter mapping is an OUT parameter contained in 
a unit, tha target parameter has to be of the kinds OUT, INOUT, or 
UNKNOWN.
- If the source of a parameter mapping is a VAR parameter contained in 
a unit, and the target parameter is of the kind IN, the mapping is 
valid if: (end of doc. Actually it's complicated and I can understand 
why the author of the doc did not find a short description of the 
allowed mappings.)

These statements have some problems:
- They only cover mappings originating from a unit. The implementations 
of the validator methods explicitly don't check mappings with rules as 
source. But e.g. a VAR parameter in a rule should not be mappable 
anywhere.
- They don't distinguish whether the mapping is from a sub-unit to its 
upper unit or the opposite direction. A mapping from an IN parameter in 
the upper unit "down" to an IN parameter in the sub-unit should be 
possible. A mapping from an IN parameter in the sub-unit "up" to an IN 
parameter in the upper unit should not be possible.
- They are not clear about VAR parameters.

That's why Gabriele and I discussed which mappings should be possible 
and which shouldn't. This is what we agreed on:


from ↓ to → | IN | INOUT | OUT | VAR
------------|------------------------
IN          |  ↓ |   ↓   |  -  |  -
------------|------------------------
INOUT       |  ↓ |  ↑↓   |  ↑  |  ↑
------------|------------------------
OUT         |  ↓ |  ↑↓   |  ↑  |  ↑
------------|------------------------
VAR         |  ↓ |   ↓   |  -  |  -

Mappings are directed from a parameter in the left column (source) to a 
parameter in the upper row (target).
↓: the mapping should be allowed from upper unit to sub-unit
↑: the mapping should be allowed from sub-unit to upper unit
↑↓: the mapping should be allowed from upper unit to sub-unit and 
from sub-unit to upper unit.
-: no mapping possible

Do you agree on this set of allowed mappings? If not, which would you 
change and why?

We look forward to your feedback!

Kind regards,
Benjamin