[rules-dev] More on Field binding

[Wolfgang Laun]

On 18/02/2013, Mark Proctor <mproctor at codehaus.org> wrote:
>
> On 18 Feb 2013, at 18:38, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:
>
> I don't like nested bindings, I think it was there before due to backwards
> compatibility.

5.1.1 permitted a binding to the field on which a constraint was based, e.g.,
   Person( $a: age > 10 || $sa: sibling.age > 10 )

>
> If we drop it for DRL6, we need to figure out a migration strategy. One
> possible way is we allow it in the parser stiff, as a config option (off by
> default, with warning of deprecated feature).
>
> Also field bindings are hangover from the Lisp days. Maybe we don't need
> property bindings anymore within patterns. Most use cases can use the
> pattern binding accessor for property access.

I'd say that field bindings must have some attraction in addition to
their heritage. Note that Lisp-ish CLIPS can access fact properties
based on a binding to the fact and the field name, but field bindings
are there all the same. (And, just because something's been used in
another language doesn't mean it's bad and must be avoided like the
plague.)

Simple field bindings is the one feature that permits me to write
rules tersely, lets me introduce an abbreviation for lengthy
factref.nameOfTheField and - if used consistently - signals a
pattern's dependency on some fact field.

And what about the positional bindings? I guess they are here to stay.
If so, it would be bizarre to the extreme if you could write
   Foo( $a, $b; )
but not
   Foo( $a: a, $b: b )

Consider: a feature requiring annotations on the unordered fields Java
class is permitted, but a very similar feature NOT requiring
annotations is not...?

Summary: Retain simple forms for binding "on the fly" to a field.
IMHO, there's no need to go overboard to permit it anywhere in complex
expressions (Edson's worry).

-W

> when
>    $p : Pattern()
> then
>     println( $p.name );
> end
>
> Field bindings allow bindings to complex expression results, involving
> nested accessors. We can use the "set" proposal I mentioned, and keep those
> outside of patterns.
> when
>    $p : Pattern()
>    $age : { $p.age * someGlobalIt }  // $age will bind to the result of the
> expression
> then
>     println( $p.name + ":" + $age );
> end
>