Sorry, my focus was on the feature, so I was not clear.
   This is how the documentation should look overall. I will use [ ] to denote groups.

   Any pattern takes the form:

<pattern_decl> ::= <variable> : <pattern>

   You can combine patterns using infix or prefix CEs "and" and "or" (both forms are equivalents). Example using "or":

<pattern_decl> [ or <pattern_decl> ]*
( or <pattern_decl> [ <pattern_decl> ]* )

   Now, there is this beast in the syntax that allow a special case of "or" that works only like this:

<variable> : ( <pattern> [ or <pattern> ]* )
  
  For the special case above, only infix "or" is accepted and the internal patterns don't accept bindings.

  I agree with you that a fix is needed: either we remove the syntax completely or we keep it for backward compatibility, but either way we need the documentation to be updated accordingly.

  I think the orthogonal form is less error prone because it is orthogonal and you would rarely use it when writing rules manually (binding to the same variable), and if you do, you are explicitly showing your intent.

  Anyway, discussion is still open, but the docs needs clarification, yes.

   []s
   Edson


2009/3/16 Wolfgang Laun <wolfgang.laun@gmail.com>
2009/3/16 Edson Tirelli <tirelli@post.com>

   This is an old discussion. Single binding on "or" is a non-orthogonal special case on the language syntax that was introduced in the early days when we only had "infix" CEs. When we started to support prefix CE, the special case was not updated, and as a result, the single binding works only with infix.

The example I've posted is practically identical to Example 7.55, or with binding. So, if it's not in the language, it'd better not be in the documentation :-)

As for the individual binding, as in

      (or $t : Trigger(fa == 1)
            $t : Trigger(fa == 2))
the documentation ought to caution against using different names, at least when these names are used on the RHS.

I agree that or groups with bindings on patterns are tricky. But is the form that's now accepted by the compiler less error-prone than the one the compiler refuses?

Wolfgang



_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users




--
 Edson Tirelli
 JBoss Drools Core Development
 JBoss, a division of Red Hat @ www.jboss.com