This is a reaction to
Let me begin with a short statement on what we (I'm not alone, here, at my
think makes a SW product (especially a programming language) attractive: we
call it "quality of service". One of the more important aspects of this
is the degree of support the programming environment provides for
especially when we consider that programmers are human, of various levels
of skill and (temporarily) subject to anything from heat to migraine.
diagnostics for as many errors as possible is one way of meeting this
knowing that the earlier one detects an error the cheaper it is. Finally, we
frequently observed that implementors of some programming environment
rarely are confronted with its real world deployment; moreover, there's
also the issue that certain application areas are subject to requirements
cherish a very high level of reliability (but not based on human factors).
sentence should not be understood as a criticism for members on any
particular team - it's merely saying that nobody knows it all.
The problem that Mark addresses in the blog is actually very simple.
Up to now, we simply have the binding of a variable to some fact or field,
which is written as
and indicates the introduction of a new identifier within the current scope.
The DRL parser is capable of detecting the reference of an undeclared
identifier, and the DRL parser will duly notify you if you try to bind an
already bound identifier. A bound identifier can be used freely, LHS and
RHS, but always in an expression.
Backward Chaining (BC) introduces the need for unification, which, of
is an algorithm and not (primarily) an issue of syntax. We need a way of
associating an identifier with any argument of the (new) query invocation
or a field of a a pattern, both in the legacy ("named") and in the newly
introduced "positional" form.
Sticking to *"Identfier **:" *throughout means that there is no way of
undeclared or duplicate usage.
Therefore, we propose -- for the "named" form to use
- *Identfier **: **fieldname ** *for binding / unifying an identifier
for the first time, and
- *Identfier **= **fieldname ** *for all successive unification
(Notice that no semantics regarding the in or out usage is implied.) For the
"positional" form, we propose to use
- *Identfier **: *for binding / unifying an identifier for the first
- just *Identfier *for all following occurrences,
- and (optionally, but probably useful) just a colon *: *for the
Traditional binding remains as it is; using "bound" variables in expressions
affected; all checks made in 5.1. can be continued.
The additional colon for positional declarative unification should not be a
especially when we consider the nice analogy to the anonymous variable being
written with an "empty" name.
For Drools programmers, the only "price" to pay is the "=" whenever
bound or unified variable*. Well, safety belts have to be put on...
A last remark: Notations using a minimum of symbols and syntactic variants
indeed more pleasing to the eye, especially when presented in small
real test, however, is whether it can stand up to being used in more
On 22 April 2011 17:06, Mark Proctor <mproctor(a)codehaus.org> wrote:
Based on the previous BC thread I've written a blog to try and
engagement. I've put this under a new thread as the other one was
getting quite long.
rules-dev mailing list