3:41 a.m.
Interesting :)
My requirements wish list:
- [minor] allow multiple function
-- Example 1: the min/max you describe
-- Example 2: for all the process of this computer: count them and sum
their cost
- [critical] function overloading
-- sum($bi.priceBigDecimal) and sum($bi.priceInteger) must use a
different function implementation
-- there's a huge pitfall/bug in drools at the moment, try these:
--- insert 2 BasketItems, one with price 0.01 and one with price 0.09.
Their sum is not 0.10 currently!
--- not even if the price property is a BigDecimal! because the drools
sum function always uses a double
-- in java try this:
--- System.out.println("Double 0.01 + 0.09 is NOT " + (0.09 + 0.01));
--- System.out.println("BigDecimal 0.01 + 0.09 is " + (new
BigDecimal("0.09").add(new BigDecimal("0.01")));
- [critical] rock-solid compilation error detection.
-- Whatever nonsense I type into a drl, the DRL compiler can't throw a
null pointer exception, must fail-fast and must clearly state which line
is causing the problem
-- To be able to allow this without making Edson's head explode, the DRL
syntax must be clearly and easily parsable...
- [major] familiarity to java, C++ and SQL
-- the syntax of some examples should be placed next to similar pieces
of codes in java, C++ and SQL (and maybe even scala etc)
Long term DRL gripes:
- [major] keywords VS non-keywords
-- when is a word a keyword and not a variable or a type?
--- When it's part of the keyword list of course. But that list changes
between versions
---- introducing new keywords break backwards compatibility
---- adding new keywords should be done reluctantly
----- I do think that "for" is a good keyword, as it's a java keyword
-- I don't like the "end" keyword, that should have been a } imho
--- usage of {} would make parsing easier, see rock-solid compilation
error detection
- [major] == VS equals
-- In java "==" means the same
-- In java ".equals" means equals
-- In drl "==" means equals
-- In drl "!=" means not equals
-- In SQL "<>" means not equals
Overall, I see 3 big themes to balance out when defining new syntax
features:
- rock-solid compilation error detection
- familiarity with java and SQL
- "blue collar language" principle (keep it simple).
-- To understand what I mean, see the trainwreck which was possible with
BGGA closures in http://www.parleys.com/#id=116&sl=3&st=5
Op 26-10-10 01:36, Mark Proctor schreef:
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet