[rules-dev] else

[Mark Proctor]

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 == "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 == "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