Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [henshin-dev] Understanding rule parameters
Hi Tassilo,

nice stuff! Comments below.

On 30.10.2014 11:59, Tassilo Horn wrote:
Hi all,

I'm currently trying to write a converter from Henshin to my own
transformation language FunnyQT.  That is, the converter takes a
*.henshin model and spits out an equivalent FunnyQT transformation.
Ideally, the generated FunnyQT transformation would have the exact
semantics as the Henshin one (possibly minus things like the order in
which matches are found).  If that's not feasible, then at least I have
a way to model transformations visually using the Henshin editor.

So currently after a day of work, I can at least translate the
structural parts of rules with NACs and PACs (but not yet multi-stuff),
i.e., matching elements, deleting old elements/refs, and creating new
elements/refs.  Now I wanted to turn to the attribute parts.

When reading the Bank example at

  https://www.eclipse.org/henshin/examples.php?example=bank

I can see that every attribute value symbol needs to be a parameter of
the rule, e.g., if you have a node

                :Client
                name = client

then client:EString needs to be a rule parameter.  I guess that's to
facilitate passing parameters matched by one rule onwards to another
rule, so you need some element for it.  In FunnyQT, I do that by passing
the return value of a rule on to the next rule.

And on

  https://wiki.eclipse.org/Henshin_Transformation_Meta-Model#Execution-time_variability:_Parametrization

I can read that when calling a rule, every parameter can be set (and
then it restricts the matches) or unset (and then the matchfinder sets
it according to the value in the host graph element).

But are unset parameters always possible?  E.g., when calling the
createAccount() rule in the Bank example with some existing client name
but no accountId, what should the result be?  Create a new Account for
the client with a random, currently unused accountId?
To my intuition, unset parameters are only possible in the attributes considered during matching, that is, deleted and preserved ones. To check if my intuition is correct, I've tried executing the createdAccount rule leaving the accountId parameter unset, just as you suggested. My intuition was confirmed: The accountId attribute - being a created one - is simply ignored. The id will be set to the default value 0 (regardless if an account with that id already exists), which is the same result as if the id attribute was absent from the rule.

In other words, the meta-model description is currently not specific enough. I will update it accordingly, if no one objects.


My problem now is that with FunnyQT, a rule's parameters must be
provided and then act as constraints while matching.  But you can
overload a rule on arity in order to have a kind of optional parameters
that, if not given, are set during pattern matching.  But clearly, I'd
need to cover all possible combinations of set and unset parameters, and
that's not possible with positional parameter lists.

So the question is: is there some syntactic way to infer from a henshin
model what's most probably a parameter that must be provided and what's
most probably a parameter that should always be set by the matchfinder?
My previous paragraph may partly answer that: Parameters in created attributes must always be provided by the user (at least, if they are not also used in preserved or deleted ones). In turn, parameters in preserved or deleted ones may or may not be provided by the user. We currently have no syntactic construct to flag parameters as being user-provided, which in your scenario may render correct treatment of the transferMoney() rule impossible. However, we've been discussing a more fine-grained parameter concept for the future and may use your scenario as input for that.

For example, in the Bank example my gut feeling says that all parameters
of createAccount() and deleteAllAccounts() are to be provided by the
caller.  But for transferMoney(), the x and y parameters are surely to
be set only by the matchfinder.  But that's only because I know that
it's unlikely that you want to transfer money only if the current saldo
is exactly 1721.97 EUR.

Well, I think that thing is a crushing my intention to keep the exact
Henshin semantics.  So I think I'll treat all parameters as "provided
values must match the attribute values in the model", and then you'd
need to define transferMoney() without the x and y parameters...

Oh, and a last question: is there a description of the possibly contents
of the Attribute:value attribute?  From the examples I can see that it
may at least contain arithmetic expressions and string concatenation in
Java syntax.
IIRC, attribute values may either be primitive values - e.g. 0 or "Hallo" -, parameters, or _javascript_ expressions. _javascript_ expressions may contain variables. Then for each variable in the _expression_, there must be a rule parameter of the same name.  Can someone confirm?

Regards,
Daniel



Bye,
Tassilo



-- 
Dipl.-Inf. Daniel Strüber
Software Engineering Research Group
Philipps-Universität Marburg, Germany, Hans-Meerwein-Str., Room 05D12
Phone: +49-6421-28-21511

Back to the top