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 Stefan,

thank for the tip. Supporting multiple _expression_ languages is definitely something we should try to do.

Cheers,
Christian


2014-10-31 11:26 GMT+01:00 Stefan Jurack <henshin.stj@xxxxxxxxx>:
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,
Christian

2014-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.


Back to the top