3:59 p.m.
Hi all,
as anticipated by Mark, I put down some ideas on how we could start
introducing some functional programming features in the DRL.
http://community.jboss.org/wiki/FunctionalProgrammingInDrools
It's needless to say that the document has to been considered just a draft
in its very first stage and any feedback or suggestion to improve or clarify
it is welcome.
Mario
4:12 p.m.
Hi Mario, that document looks great.. I will take some time to read it and I
will try to give some feedback.
I was playing with cypher (from neo4j, a graph oriented DB) (total newbie on
that) but looking at your in line acc functions I think that we can take
some concepts from cypher and apply them in DRL.
Cheers
On Wed, Oct 19, 2011 at 5:59 PM, Mario Fusco <mario.fusco(a)gmail.com> wrote:
--
- CTO @ http://www.plugtree.com
- MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jugargentina.org
- Co-Founder @ http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
3:08 a.m.
New subject: Functional programming in Drools: closures
Interesting stuff.
This is basically
"closures" which will be available in JDK 8
+ LHS closure pattern support
1) About "closures" which will be available in JDK 8:
Since functions contain Java code, which is imperative, not declarative,
I don't consider that DRL turf any more.
*Our closure syntax should there should be exactly the same as Java 8.*
Here's their syntax, which looks the same on first sight, but the devil
is in the details (= unreleased spec):
http://mail.openjdk.java.net/pipermail/lambda-dev/2011-September/003936.html
Either we wait for JDK 8 to be released to support closures (current
release date is 2012 according to Mark R.'s "plan B" that released JDK 7
in 2011)
or we implement it just like the JDK8 with the exact same syntax (which
is a LOT of work).
2) About LHS closure pattern support.
This builds on top of 1) to allow usage of closures in the LHS.
Cool stuff, I like the piping idea.
Op 19-10-11 23:12, Mauricio Salatino schreef:
--
With kind regards,
Geoffrey De Smet
6:21 a.m.
New subject: Functional programming in Drools: closures
I would also like to keep it as close to Java as possible.
There are few problems here:
* It could never go beyond Java
* We are using Java 5 and just considering Java 6, this would be a huge leap :-)
But then again if we don't use the Java way, then what will we do when Drools reaches
Java 8, support both?
Toni
On Oct 20, 2011, at 11:08 AM, Geoffrey De Smet wrote:
6:49 a.m.
New subject: Functional programming in Drools: java 5 minimum with java 8 support
The minimum java version we require (currently java 5)
need not be the same as the maximum java version language features we
support.
For example, drools 6 could require at least java 5 to run, but
- if source>=7 and target>=7 you can use switch(String) and other coin
stuff in DRL functions
- if source>=8 and target>=8 you can use closures in DRL functions
The point is... drools-core source code itself can't use that stuff
(unless it's in the extension module drools-core-jdk7).
Spring 2.0.0 did something similar IIRC: it required at least JDK 1.4,
but if it detected JDK 1.5 you could use annotations too.
Note: despite all that, I still wish we move the minimum java version to
6 :)
Op 20-10-11 13:26, Wolfgang Laun schreef:
--
With kind regards,
Geoffrey De Smet
7:04 a.m.
New subject: Functional programming in Drools: java 5 minimum with java 8 support
Another alternative would be to freeze one Drools version as "last one for
Java 5", and proceed undauntedly to new shores. But there is also the issue
of suppor - don't know whether you buy a guarantee of unlimited progress
towards new features while standing still at some Java version.
Also: Providing DRL features that are only available with Java 6/7/8... will
make documentation even more of a maze as it is now.
-W
On 20 October 2011 13:49, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com> wrote:
5:40 a.m.
Very well written. Thank you.
Whether there's the need for a Drools-prvided library (beyond the things
there are now as accumulate functions) remains to be seen.
I still maintain the notion that it should be possible to obtain quantifier
results and continue LHS evaluation, and I think that the functional
approach would make this easier. It can be done now, using a dedicated
accumulate function, but there's the issue of escaping from the iteration
when the final result is established.
-W
On 19 October 2011 22:59, Mario Fusco <mario.fusco(a)gmail.com> wrote:
6:15 a.m.
New subject: Functional programming in Drools: Brackets and Commas
I'm just asking if we can drop the brackets and maybe even the commas to get a cleaner
look.
The goal is to pick 10 students who have the best score. We do not want to give out who is
the best, so the student list is ordered by student names. I'm sure that there are
some syntax errors, but hopefully I got most of it right.
function String name( Student student ) => student.name;
function String score( Student student ) => student.score;
function List<T> orderBy( Comparable => String field, List<T> list ){
orderBy( ( first, second ) => field( first ).compareTo( field( second ) ), list );
}
function List<T> orderBy( (Comparable, Comparable) => int comparator,
List<Comparable> list ){
## sort ##
}
function (int, List<T>) => List<T> top( int number, List<T> list )
=> list.subList( 0, number );
Student( )
|> collect
|> top( 10, orderBy( score ) )
|> orderBy( name )
vs.
Student( )
|> collect
|> top 10 orderBy score
|> orderBy name
Another example. A function returning a function. Let' s take the bottom 3.
function (int, List<T>) => List<T> bottom(){
(number, list) => list.sublist( number, list.size() -1 );
}
Student( )
|> collect
|> orderBy( score )
|> bottom()( 3 )
vs.
Student( )
|> collect
|> orderBy score
|> bottom 3
And of course you could have a function returning a function returning a function and so
on and you get doSomething()(1)("Toni",29)()("more text for
testing").
Toni
On Oct 19, 2011, at 11:59 PM, Mario Fusco wrote:
6:25 a.m.
New subject: Functional programming in Drools: Brackets and Commas
On 20 October 2011 13:15, Toni Rikkola <toni.rikkola(a)gmail.com> wrote:
Do you mean parentheses, i.e. ()?
How will a parser be able to determine the end of a parameterlist if there
is one call inside the other?
-W
6:43 a.m.
New subject: Functional programming in Drools: Brackets and Commas
Yes parentheses.
And I don't know the answer to the next question, just asking because I have seen it
work in other languages :-) Not a must have, in other cases using parentheses is cleaner.
Toni
On Oct 20, 2011, at 2:25 PM, Wolfgang Laun wrote:
6:57 a.m.
New subject: Functional programming in Drools: Brackets and Commas
On 20 October 2011 13:43, Toni Rikkola <toni.rikkola(a)gmail.com> wrote:
Certainly not with overloading.
Not a must have, in other cases using parentheses is cleaner.
Eliminating all that's redundant has the downside that recovery from syntax
errors is difficult, if not impossible. Typically, within each NT, you have
a set of delimiters where you can assume that some higher level NT
terminates (a closing bracket/brace/parenthesis) or enters another
subordinate NT (comma, semicolon).
Also, don't forget the help you get in an editor when you close a b/b/p by
highlighting the opening counterpart.
Architects have a name for this sort of thing, the German term is
"Orientierungsqualität", which could be translated as "guidance
quality".
Its lack in modern quarters is frequently appalling ;-)
-W
5:22 p.m.
New subject: Functional programming in Drools: Brackets and Commas
On 20/10/2011 12:43, Toni Rikkola wrote:
It does look nice, however languages that allow
this tend to be more
limited in scope. I was thinking about this myself the other day -
optional parenthesis and optional comma separation. We'll look into it
as a secondary consideration, it may become possible for some limited
use cases....
Mark
8:07 a.m.
New subject: Functional programming in Drools: Brackets and Commas
Toni,
correct me if I'm wrong: your suggestion looks very similar to what you do
in Haskell where the syntax without parenthesis and commas is allowed by the
fact that in this language every function officially takes only one
parameter, while the functions that apparently accept more than one argument
are actually curried functions**. You can find more explanations about this
syntax, for example, here:
http://learnyouahaskell.com/higher-order-functions
Despite I like this syntax because it allows to eliminate some punctuation
making the code often (but not always) more readable I also see 2 main
problems with it:
1. It implies a larger use of curried functions and I am not sure that the
biggest part of Drools users will feel comfortable with them.
2. It will bring our syntax even farther from the one that will be available
in Java 8.
In general I agree with Geoffrey when he wrote that we should give a look at
the upcoming Java 8 syntax and stay as close as possible to it. Nevertheless
I also think that what will we have in Java 8 is not enough to make it a
functional language and, in the same way, not enough to have in the DRL the
expressiveness and features of functional programming.
My suggestion is that our syntax should be a superset of the Java 8 one,
adding to it things like currying, functions piping and tuple. I hope I
demonstrated how this features could be useful for us in my article. In this
way we will have the twofold advantage of providing a syntax that won't look
too much alien for the Java developers and possibly making our work easier
(if we will decide to build it on top of Java 8) because in that case we
will need only a (hopefully thin) layer that translates in plain Java the
functionality not natively covered by it.
Mario
1:20 p.m.
New subject: Functional programming in Drools: Brackets and Commas
Yes, I was thinking about Haskell :-)
I guess Haskell is one of those languages that nobody complains about because nobody uses
it. Drools should indeed be easy to learn for Java developers.
Toni
On Oct 20, 2011, at 4:07 PM, Mario Fusco wrote:
4893
days inactive
4894
days old
15 comments
6 participants
participants (6)
-
Geoffrey De Smet -
Mario Fusco -
Mark Proctor -
Mauricio Salatino -
Toni Rikkola -
Wolfgang Laun