On Tue, 28 Oct 2003, Andre Beck wrote:
I think the latter is the case. ;-) At least IRML does not allow
such loops. When I talked about the re-evaluation of rule conditions
I did not mean that a single rule can or should be evaluated more
than once for a given message. Rather what I meant was that if the
same message property is referenced in two different rules, then the
rule processor must not assume that the property value will be the
same for both rules.
Ah, I see. In P, since it has variables, the same caveat becomes even
more confusing for rule writers, I think. In IRML, the rule writer
should assume that every external property may change between service
invocations (at least). In P, the rule writer may have to assume that
even local variables change between service invocations (at least).
It would be nice to either avoid variable changes or at least make
them less transparent. In your opinion, what is more important:
- optimizing performance when storing potentially
large expression values in a variable
- optimizing programmer understanding when using
variables (i.e., making the interface more natural
so that programmer's expectations match reality)
I wonder if it make sense to offload the above decision to programmer?
We could give rule writers explicit control over macro-versus-constant
choice by introducing references (parameter-less macros) in addition
to constant variables. For example,
/* no performance penalty, natural/expected results */
constant name := small_value;
/* no performance penalty, possibly confusing results */
reference name := huge_value;
/* no performance penalty, possibly confusing results */
reference name := small_value;
/* performance penalty, natural/expected results */
constant name := huge_value;
What do you think? Is it worth the trouble supporting the above
interface? Or should we make this decision for the programmer, in P
Core?
Or would it be possible to delegate the decision to module writers,
like I proposed for string case sensitivity support? Each object would
be either copied or referenced, depending on objects type, as defined
by object creator (a module):
/* no performance penalty, natural/expected results */
name := small_object.cheap_operation(small_value)
/* no performance penalty, possibly confusing results */
/* copy small_* and cheap_operation, */
/* reference huge_object and expensive_operation */
name := huge_object.cheap_operation(small_value);
name := huge_object.expensive_operation(small_value);
name := huge_object.expensive_operation(huge_value);
name := small_object.expensive_operation(small_value);
name := small_object.expensive_operation(huge_value);
...
The latter approach puts the optimization burden on module writers,
which is good. Should we combine the two:
/* rely on expression's module(s) to copy or reference */
name := expression;
/* force copying: performance penalty but expected results */
constant name := expression;
Comments? Better ideas?
I don't think it's a good idea to get into the business of loops and
loop prevention by allowing the rule processor to evaluate a rule a
second time if a message propery value changes. In fact, I think
such behavior would potentially lead to very unintended results
because the order in which rules (and services for that matter) are
processed can make a big difference. The order in which rules are
processed should be determined before they are evaluatated.
I agree.
Alex.