Hello Mark,

I've been thinking about this, on and off, for 5 days now, and I still
fail to see the benefits. Perhaps there are more convincing use cases
than those in your original mail?

Notice that the "for" scope now contains two kinds of bindings: one that
is strictly local to for(...) (bi below) and another one that must be exported
such as the binding $s in

  for( bi : BasketItem( customer == $c ); $s = sum( $bi.price); )

This will be confusing.


I fail to see the usefulness of filter() in

   for( $b2 : BasketItem( customer == $c ); filter( $b2, $b2.price > 100) )

where one can better (and perhaps even more efficiently) write

   for( $b2 : BasketItem( customer == $c, price > 100) )

I don't understand what this construct should achieve:

    $r = $bi | map( $, $.price * 2) | filter( $, $.price < 100);

Given that $bi iterates over BasketItem objects, the first map would create
a numeric value by doubling $bi.price, so I suppose the next pipeline transmits
numbers so that filtering applies to - what? java.lang.Number? Then it can't be
$.price; it could be $.floatValue or similar. But again: the entire selection
could be written as a constraint of the BaskerItem pattern. Creating a
collection just for determining a count isn't straightforward.

The idea of accumulate is to produce a scalar result from processing a
collection of facts. It would indeed be useful to extend this so that a result
tuple can be constructed. But this could be achieved by a complex
accumulate function that returns an object with multiple fields;
in fact, min/max/count/avg/sum can be wrapped into a single function
"stats" returning an object of class "Statistics" with appropriate fields.
Any filtering on the result can be written as a constraint on that
temporary fact pattern of type Statistics, e.g.:

Statistics( $min: min, $max: max )
  from accumulate( $bi: BasketItem( $p: price ) stats( $p ) )

All that remains is the syntactic sugar that's provided by
   x in [0..4]
   y in [0..4]
   $c : Cell( row == y, col == x );
as a on-the-fly pattern for selecting other patterns. Again, this could be
written more concisely as
  $c : Cell( row >= 0 && <= 4, col >= 0 && <= 4 )
and a (minor) extension such as a set expression might simplify this:
  $c : Cell( row in [0..4], col in [0,1,2,3,4] )

Regards
Wolfgang

On 26 October 2010 01:36, Mark Proctor <mproctor@codehaus.org> wrote:
We are thinking of moving "accumulate" to a simple "for" keyword. We
might allow 'in' and 'from' to be used interchangably and allow ';' semi
colons to separate the sections. I'm also wondering ho we could allow
function pipelines for the function part of the element. We also need
type inference and "default" return values.

So here are some code snippets to show what I'm thinking, as
improvements over what we do with accumulate now.

// Simple 'or' very simlar to accumulate before. ; for section
separating. With a new boolean section at the end to decide whether to
propagate or not. Will probably use '=' for function assignments.
$c : Customer()
for( $bi : BasketItem( customer == $c );
        $s = sum( $bi.price);
        $s > 100 )

// Multiple functions are ofcourse allowed
$c : Customer()
for( $bi : BasketItem( customer == $c );
        $mn =min( $bi.price),
        $mx = max( $bi.price); )

// As are multiple patterns, and as before patterns can come 'from' an
expression and with type inference we can get some nice compact text:
for ( x in [0..4]
      y in [0..4]
      $c : Cell( row == y, col == x );
      $avg = avg( $cell.value );
      $avg > 100 )

The above is possible now with the following:
Integer( this > 100) from
    accumulate( x : Integer() from [0, 1, 2, 3, 4]
                y : Integer() from [0, 1, 2, 3, 4],
                $c : Cell( row == y, col == x ),
                avg( $c.value) )

I think the proposed additions reall help with declarative readability.

The normal chaining of elements is supported:
$c : Customer()
for( $b1 : BasketItem() in
          for( $b2 : BasketItem( customer == $c );
                 filter( $b2, $b2.price > 100); );
        $a = avg( $b1.price ); )

'for' will have a default return type for each bound function. In this
case it returns a single value $a, if there are multiple bound results
an array/map must be used for access.

I also think we should allow pipelineing of functions, much as you would
do in a normal functional programming, possibly using haskell like
"stream fusion" capable functions.

// '$' refers to the magic contents of the function which is "piped" in.
So $bi is piped to map, $ refers to each value evaluated in the
function, with type inference. 'map' results are piped to 'filter'. The
final results are assigned to $r.
$c : Customer()
for( $bi : BasketItem( customer == $c );
        $r = $bi | map( $, $.price * 2) |
                       filter( $, $.price < 100);
        $r.size > 100 )

More ideas welcome :) But I think this opens up some very interesting
areas for DRL, with something that will hopefully feel more natural for
developers.

Mark

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