[rules-dev] else
Mark Proctor
mproctor at codehaus.org
Thu Aug 18 12:36:30 EDT 2011
My current decisions are| vs < I'm tempted ot try | so that it fits with
the filters, to avoid additional symbols.
I'm relatively happy with {name} and {...code...}, the prior can just be
considered a literal function call, where as the later is an anonymous
literal function.
I do want to resolve the switch statement. I don't like repeating 'from'
for each option:
$o : Object() from stream
( A() > [a] from $o or
B() > [b] from $o or
C() > [c] from $o )
Possibly a ; separation, similar to the planned accumulate changes.
case( Object() from stream;
A(),
B(),
C() )
btw the acc planned is
acc( CE*;
<func>*;
<guard>? )
acc( $o : Order();
$min : min( $o.value ),
$max : max($o.value);
$min > 100 && $max < 100 )
Mark
On 18/08/2011 15:48, Mark Proctor wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110818/cf298dda/attachment-0001.html
More information about the rules-dev
mailing list