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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
--
With kind regards,
Geoffrey De Smet
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
