[rules-dev] else
Mark Proctor
mproctor at codehaus.org
Thu Aug 18 12:15:56 EDT 2011
On 18/08/2011 16:48, Geoffrey De Smet wrote:
> My 2 cents
>
> - I don't like using {} for something that doesn't contain code (the
> closer we stick to java the easier it is for our users to learn it).
> It would be nice if would do some sort of annotations and then do:
> @ElseLabel else1 : A()
> That way we can avoid adding new keywords or special chars (the latter
> which isn't intuitive in this case).
>
> - It took me a couple of q&a with edson to understand how many time it
> would fire under which conditions.
> I wonder if we really need this complexity if we can avoid DRY for the
> users in a more generic way.
> For example, with ruleParts:
>
> rulePart part1
> when
> $p : Person( name == "darth" )
> end
>
> rulePart part2
> when
> Address( person == $p, city == "deathstar" )
> end
>
> rule darthOnDeathstar
> when
> $part1
> $part2
> then
> sout("darth is home")
> end
>
> rule darthNotOnDeathstar
> when
> $part1
> not ($part2)
> then
> sout("darth is away")
> end
>
> This is lower level, but think about:
> */In the RHS, you can easily extract methods into java classes or DRL
> functions,
> but on the LHS, this isn't possible, right?/*
This one would probably be address by looking properly into a Lisp like
Macro system.
Mark
>
> Op 18-08-11 16:48, Mark Proctor schreef:
>> The other consideration of "<" is that we are thinking of using |"
>> for filters.
>> A() | distinct
>> It may be we can just achieve this with "|" so we only introduce a
>> single symbol and the | can work to both the left or right side of a CE
>> {failabel1} | A() | {passlabel2}
>>
>> which could also allow
>> A() | distinct | {passlabel2}
>>
>> Mark
>> On 18/08/2011 15:03, Edson Tirelli wrote:
>>>
>>> Mark,
>>>
>>> The [] syntax for the labels will clash with the sequencing
>>> syntax we've been discussing. Possibly {} or a unique separator:
>>>
>>> {else1} A()
>>>
>>> else1 := A()
>>>
>>> else1 ?= A()
>>>
>>> Considering that Patterns can also take bindings, probably {} is
>>> more distinct:
>>>
>>> {else1} a : A()
>>>
>>> My vote:
>>>
>>> when
>>> {else1} Person( name == "darth" ) // works on patterns
>>> A()
>>> {else2} B()
>>> then
>>> ....
>>> otherwise.else1
>>> ...
>>> otherwise.else2
>>> ...
>>> end
>>>
>>> Will we support unlabeled "else" as well?
>>>
>>> when
>>> A() and B()
>>> then
>>> ...
>>> otherwise
>>> ...
>>> end
>>>
>>> If so, what will be the semantics of it? What happens if an A()
>>> is inserted but not B()? vice-versa? What happens if C() is inserted?
>>>
>>> Regarding inline "consequences", at the moment I am not really a
>>> fan of it. I think it complicates the syntax unnecessarily at this
>>> point but I can be convinced. The support to else by itself is a big
>>> step forward as you know users frequently ask for that.
>>>
>>> My .02c.
>>>
>>> Edson
>>>
>>> 2011/8/18 Mark Proctor <mproctor at codehaus.org
>>> <mailto:mproctor at codehaus.org>>
>>>
>>> We have been looking into designs around else, so here are our
>>> initial
>>> brain storming ideas, which aims at doing more than just else, but
>>> handling signal processing like situations. "else" is always
>>> triggerd by
>>> the failure of a left propagation. In effect an named "else"
>>> block is
>>> just another terminal node that will result in an activation on the
>>> agenda. It will have access to declarations prior to the failure of
>>> propagation in the network.
>>>
>>> // Possible syntaxes
>>> [name] ( CE+ ) // no symbol
>>> [name] | ( CE+ )
>>> [name] < ( CE+ )
>>>
>>> 1)
>>> when
>>> [name1] < Person( name == "darth" ) // works on patterns
>>> A()
>>> then
>>> ....
>>> then.name1
>>> ...
>>> end
>>>
>>> 2)
>>> when
>>> $p : Person( )
>>> [name1] < eval( $p.name <http://p.name> == "darth" ) //
>>> works on evals
>>> A()
>>> then
>>> ....
>>> then.name1
>>> ...
>>> end
>>>
>>> 3)
>>> when
>>> [name1] < ( Person( name == "darth" ) and Address( city ==
>>> "death
>>> star" ) // works on groups
>>> A()
>>> then
>>> ....
>>> then.name1
>>> ...
>>> end
>>>
>>> This could actuall be extended to have inline "then" too. In
>>> this case
>>> when their is a success propagation on that node it will result
>>> in an
>>> activation placed on the agenda that has access to all the prior
>>> bound
>>> declarations.
>>>
>>> 1)
>>> when
>>> Person( name == "darth" ) > [name1] // works on patterns
>>> A()
>>> then
>>> ....
>>> then.name1
>>> ...
>>> end
>>>
>>> 2)
>>> when
>>> $p : Person( )
>>> eval( $p.name <http://p.name> == "darth" ) > [name1] //
>>> works on evals
>>> A()
>>> then
>>> ....
>>> then.name1
>>> ...
>>> end
>>>
>>> 3)
>>> when
>>> ( Person( name == "darth" ) and Address( city == "death star" ) >
>>> [name1] // works on groups
>>> A()
>>> then
>>> ....
>>> then.name1
>>> ...
>>> end
>>>
>>> This can be used with 'or'
>>> when
>>> ( A() > [a1] or
>>> B() > [b1] or
>>> C() > [c1] )
>>> D()
>>> then
>>> ...
>>> then.a1
>>> ....
>>> then.b1
>>> ....
>>> then.c1
>>> ...
>>> end
>>>
>>> It's a little tricker but in theory we can do this before/afer
>>> the 'or' too
>>> This can be used with 'or'
>>> when
>>> [x1] < ( A() > [a1] or
>>> B() > [b1] or
>>> C() > [c1] )
>>> D()
>>> then
>>> ...
>>> then.a1
>>> ....
>>> then.b1
>>> ....
>>> then.c1
>>> ...
>>> then.x1
>>> ....
>>> end
>>>
>>> We could allow [name] as just an inline creation to an
>>> activation that
>>> always passes, which with 'or' could provide a "default".
>>> when
>>> [x1] < ( A() > [a1] or
>>> B() > [b1] or
>>> C() > [c1] or
>>> [default] )
>>> D()
>>> then
>>>
>>> Of course both could be supported at the same time
>>> [afailed] < A() > [asuccess]
>>>
>>>
>>> We could further allow just an inline code block, isntead of an
>>> inline
>>> reference to a block {...code here...} instead of [name1].
>>>
>>> We can also use this to do switch like operations, for erlang style
>>> signal processing, although i'd like to see an improvemet to the
>>> syntax
>>> here, just not sure what it would be...
>>> $o : Object() from stream
>>> ( A() > [a] from $o or
>>> B() > [b] from $o or
>>> C() > [c] from $o )
>>>
>>> Where as 'or' currently works like java's "|" single operator,
>>> i.e. all
>>> logical branches are tested. We could add a short cut or operationr
>>> 'sor' that would work like "||", so once the first CE matches in
>>> an 'or'
>>> block the rest are igored. We could even consider an 'xor' ....
>>>
>>> Finally there is no reason why we couldn't allow other CE's
>>> after the <.
>>> Which would provide for very rich signal processing. For
>>> instance. If
>>> A() fails, it'll propagate to B, if B() fails it'll activate [a1]
>>> [a1] < B() < A()
>>> This can be nested and using using parenthesis to show groupings.
>>> ( [a1] < B() > [b2] ) < A()
>>>
>>> Anyway more food for thought, enjoy :)
>>>
>>> Mark
>>>
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>>
>>>
>>> --
>>> Edson Tirelli
>>> JBoss Drools Core Development
>>> JBoss by Red Hat @ www.jboss.com <http://www.jboss.com>
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
> --
> With kind regards,
> Geoffrey De Smet
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110818/a2793c80/attachment.html
More information about the rules-dev
mailing list