[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[henshin-dev] Understanding rule parameters
|
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?
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?
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.
Bye,
Tassilo
--
Dipl.-Inform. Tassilo Horn | Room: B015
University of Koblenz-Landau, Campus Koblenz | Phone: +49 (261) 287-2745
Institute for Software Technology | Mail: horn@xxxxxxxxxxxxxx
Universitätsstr. 1, 56070 Koblenz, Germany |