[great-users] Order properties/guarantees in GreAt transformations

[Simon Görke]

Hello everybody,


I have a Great transformation which needs to set an attribute to a unique
(integer) ID. 
My key requirement is that, for a given atom/model, the ID is assigned
identical if 
a. two successive transformation runs are performed on the same input model
(same rule.exe).
b. the rule is not changed structurally in the graphic modelling, but it is
recompiled (e.g. because some unrelated attribute setting needs fixing)

What I did is using a global variable which is initialized once to "0" and
increment it after each assignment to the ID attribute.
Unfortunately this assignment is distributed over several rules like so
(hope ascii graph survives mail formatting):

 
/-------------------rule2_matchY_createX ---> setID_of_X
rule1_Init_globalvar_to_0 ----<
 
\-------------------rule3_matchZ_createX ---> setID_of_X

I.e. rule2 and rule3 are parallel rules which contain different matching
patterns but result in newly created atoms of same type "X". 
(This is a simplified example - actually my rules are already existing and I
have to add this ID property to them retroactively / rule which create X are
widely spread in the transformation...)

Obviously, this approach was too naïve wrt the requirement above, i.e. IDs
are NOT ALWAYS assigned deterministically between two successive runs.
I guess there are (at least) two problems with this:
1. matching in rule2 is not deterministic wrt the output sequence of X-type
atoms. Same for matching in rule3.
2. call order of rule2 and rule3 is not deterministic after recompilation
(due to Great c++ code generation being not deterministic). Not sure about
this - maybe great generates the functions top rule first or something?
Then, this would be a non-issue.

So:
- if only 1. Is correct and 2. NOT, I could merge (serialize) the outputs of
rule2 and rule3 into one rule and try to find a unique property which can be
used for sorting before actually assigning the ID. 
Problem here: only one output port can be sorted and the attributes of this
FCO alone are typically not enough to make order distinct; so I have to
include other objects, but there is no direct way I am aware of to implement
multi-property sorting except for (complex) code-based tree-navigation
within the compare function
- if both assumptions 1. and 2. are correct, it seems my only chance to
implement this is a strictly serial rule sequence / NO parallel branches
(results in really ugly rule implementation for me) - 
I know those are hard to answer in general but:
- are there any additional sources of indeterminism which I did not
realize..?
- better idea to tackle this for an existing (non-trivial) transform?

Thanks
Simon