| Re: [henshin-dev] Understanding rule parameters |
Hi Christian,
very promissing and in particular pretty fast is MVEL. It's definitely worth a look. It even provides precompiled statements for even more improved performance.
regard, stefan
Am 31. Oktober 2014 08:34:07 MEZ, schrieb Christian Krause <henshin.ck@gmail.com>:One last comment: we have been also discussing allowing multiple script languages for attribute calculations. But currently we only support JS.Cheers,Christian2014-10-30 16:55 GMT+01:00 Tassilo Horn <horn@xxxxxxxxxxxxxx>:Daniel Strüber <strueber@xxxxxxxxxxxxxxxxxxxxxxxxx> writes:
Hi Daniel,
>> 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.
Ok, got it.
>> 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.
That's bad enough for my translation. ;-)
> 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.
Well, I guess the "certain parameters may or may not be set" stuff can
be considered a feature. My problem is just that there's no
straight-forward translation to FunnyQT. But that's not your problem.
>> 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?
Oh my god! So I can have
"[x,y,z].reduce((function(o,i){return i + o;}),0)"
as a valid value in the value-slot of a create/preserve-argument? Well,
cool but not really convertible. ;-)
Then I guess a general Henshin-to-FunnyQT translation isn't really
possible. But at least one can use the Henshin editor to define FunnyQT
rules where the FunnyQT parameter semantics apply and Attribute
value-slots can contain arbitrary Clojure expressions instead of JS
expressions. Well, still pretty nice.
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 |
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/henshin-dev
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/henshin-dev
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.