This strategy works for every kind of Unit that holds multiple
subUnits. Providing a visualization that omitts those wrappers and
uses the ordering of ParameterMappings would be syntactic sugar that
may be provided by the graphical editor. The underlying model can -
and therefore should - be created using the existing semantics. As
you said before, people are using henshin and are creating
transformations based on the newest version. If we change the
semantics now, we will have to deal with the fact that those
modifications are part of the language when it comes to developing
the next increment. Every design decision may become a straitjacket,
no matter how far back it dates. The current semantics are merely a
milestone, but they are a quite good basis from which we can go on
in almost any direction. The proposed changes would pose an
unneccessary restriction for future development.
After all, using a wrapper is pretty easy. Once you realize how to
deal with such a case it almost becomes natural. To break it down:
1) A unit defines an invocationcontext for other units.
2) An invocationDefinition consists of a unit and its incoming and
outgoing parametermappings in a given context.
3) A unit may have exactly one invocationDefinition per context.
4) An invocationDefinition may be triggered/invoked several times in
a context(i.e. a unit occurs several times as subUnit).
5) A Unit U is semantically equal to a strict SequentialUnit S that
holds only one U as subUnit(+parametermappings).
6) U and S are different units and therefore may have different
invocationDefinitions in a given context.
Am 15.01.2012 08:30, schrieb Christian Krause:
Hi Gregor,
thanks for the description of the workaround. I have to deal with
the possibility that someone tries to specify a scenario with
multiple invocations of the same unit with different parameters
(not only in sequential units) in the graphical editor though. For
now, I think I will encode this information using the order of
ParameterMappings -- thats the best we can do at this stage.
cheers,
christian
Am 15.01.2012 00:39, schrieb Gregor Bonifer:
I see your point. Those changes are too extensive for now.
As starting point of this discussion you illustrated a scenario
which does not work with the current interpretation. However
there is a workaround by means of the existing interpretation:
Given a Unit U with parameter X. You want a sequence which
invokes U twice with different values for X. Using a
SequentialUnit S with Parameters A and B which has U as subUnit
twice won't work because there would be two ParameterMappings
initializing the *same* parameter X (A -> X and B -> X).
If you create a wrapper W for U (e.g. a SequentialUnit with U as
subUnit, a parameter WP and a mapping WP -> X ) and replace
one occurance of U in S the subUnits would become virtually
*different*. So the subUnits of S would be U and W. Those have
*different parameters* which can be initialized without creating
conflicting ParameterMappings(A -> X and B -> WP).
I attached the mail in which I sketched the result (I used two
wrappers there).
The existance of a workaround should at least allow us to avoid
any makeshift solution. Especially since I am sceptical that a
good solution will be found as long as the primary rationale is
to not change the model.
Regards,
Gregor
Am 14.01.2012 20:13, schrieb Christian Krause:
Hi Gregor,
Am 14.01.2012 17:46, schrieb Gregor Bonifer:
I am not convinced, that this is the best way. A
SequentialUnit that uses another Unit x times would need
identical ParameterMappings x times. This will occur when
migrating a CountedUnit with a count of x > 0. Derived
visualizations might be able to deal with this in an elegant
way, but the effect on the tree-based editor is fatal.
I do not consider this as "fatal". It is a workaround -- true.
But at least we won't have to change anything in the model,
and the additional ParameterMappings in the migrated models
are not as bad as you say.
As
I illustrated earlier, it is possible to build a workaround
with the current model. So there is no actual need to change
anything at the moment.
I'm not convinced yet that it works and as I said before, I
would find it good if we could solve this issue without
invasive model changes.
However, I think it would be a good idea to think about the
controlflow definition in general. There are some more
issues that should get some attention. For example there is
the problematic aspect that a TransformationSystem becomes
cluttered with transformation fragments. Defining a complex
transformation requires to create units in the TS that have
no meaning by themselves. Not only is this affecting the
readability but this also means that it is not possible to
keep up the notion of a TS as graph grammar, i.e. there is
no distinction between productions and production fragments.
If we address this issue (and I sincerely hope so) there
will probably be changes regarding the containment of units.
This would be a much better context for thinking about
modelling invocations in a mapping-friendly way.
We have to deal with the fact that we have an existing model,
that people *are* using it right now and that all bigger
structural changes make the migration more complex and
error-prone and that people might get confused and even mad if
we make such radical changes. We have to live with most of the
design decisions made already in the beginning of the project.
I'm not saying we should not think and talk about it, but I
believe the code base is not yet mature enough to plan a
"Henshin2" if you will.
So I think it is the best if we stick to small and local
changes for now and postpone discussions about more general
questions and future directions. Please keep also in mind that
the next release is planned for in 6-8 weeks and that we still
have to do a lot of work to finish the things on our current
agenda.
Cheers,
Christian
PS: We avoided containment of units in order to be able to
reuse them. There are always pros and cons...
Am
14.01.2012 16:52, schrieb Christian Krause:
How about this: for the execution, every ParameterMapping
can be used only once and the choice for a
ParameterMapping is done based on their order. I think
that should work... (?)
On 01/14/2012 04:32 PM, Christian Krause wrote:
Sorry, I misunderstood your previous mail. the order
does not work, I see...
On 01/14/2012 02:48 PM, Christian Krause wrote:
Hi Enrico,
so the order of ParameterMappings determines which one
is used when? This is quite subtile and it must be
specified exactly what the semantics is. For example,
assume the same setting as before, so with the
ParameterMappings
1) A -> X
2) B -> X
But now assume that the subUnit is called 3 times in
the sequential unit. What value is assigned to X for
the third invocation? A, B, or nothing?
Cheers,
Christian
PS: I hope this can be resolved without changing the
model.
Am 14.01.2012 10:44, schrieb Enrico Biermann:
I am not sure I see the problem. The parameter
relation mapping between a unit and one of its
subunits should be injective. The parameter relation
mapping between a subunit and its unit (also stored
in the unit) should be injective. Any non-injective
relation will always have the problem of having to
choose which value to apply to a subunit (or the
unit). Even if A->X, B->X wouldn't be
ambigous in the first place. Trying to put them in a
proper order like A->X first, then B->X second
is futile at the moment.
Note that the injectivity apply only between the
unit and exactly one subunit. You can reuse unit
parameters for different subunits as well as set
unit parameters with parameters from different
subunits.
One possiblity would be
A -> X
B -> Y
And allow a syntax to map multiple parameters to a
single field for example:
attribute = {X|Y}
Another would be to use guards for parameter
mappings i.e. allow a specific mapping only if the
condition is true. However I have no idea what kind
of information you would need here. Probably things
like state of parameters and information about
previously executed subunits.
I am not happy with either of these solutions and
not sure whether the injectivity restriction is that
bad.
Regards,
Enrico
On 13.01.2012 23:20, Christian Krause wrote:
Assume you have a sequential unit with parameters
A and B in which another unit with a single
parameter X is called twice. The first time, it
should be invoked with A, the second time with B.
So I have to add the following parameter mappings
to the sequential unit:
A -> X
B -> X
But now, when the subunits are invoked, the engine
should get into trouble because it does not know
whether to pass A or B for X.
On 01/12/2012 12:53 PM, Stefan Jurack wrote:
Right, analogously to method calls where the caller passes parameters to
and fetches parameters from the callee.
Am 12.01.2012 12:26, schrieb Christian Krause:
Hi,
parameter mappings are managed by the parent transformation unit,
correct?
chhers,
christian
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
|