We will maintain DRL6 compatability, that won’t go anywhere. But we do want to modernise our language, it’s evolve organically and has had compatibility since 2005 - wit this it’s brought a lot of quirks and inconsistencies. We want a strong emphasis on good tooling and IDE code completion.

Dialects will go, instead we’ll have a single consistent language, that will very close to java, probably a superset. With a few additions to improve it’s readability for rules. We are looking to extend the JDT compiler for this. Some examples of the java extensions we’ll do:

https://developer.jboss.org/wiki/Drools7Java-likeLanguage

However we will make it easier for other people to create their own languages now, and look for clojure or scala rules. We are reworking our core, making it cleaner and easily extensible for other language implementations - with our Executable Model. As well as trying to appeal to pure java developers, that will never touch DRL, no matter how close to java it is.

http://blog.athico.com/2014/09/the-birth-of-pojo-rules.html

https://developer.jboss.org/wiki/ExecutableModel

DRL7 will be a more technical, more java like language. We will also become more strict. For instance currenly rules and agenda-groups can go in any file and be mixed and matched. I want to have one file per group, and  all rules in that file are in the group. agenda-groups will incorporate some of the functionality and found in of Venus Modules and RuleWorks Blocks. Where they are callable with return values, and have life cycles you can hook into - on enter, on exit, on empty.

We are also exploring some simpler execution semantics, around @All. Inspired by what we’ve found working with Games and game loops. See the invaders game

https://developer.jboss.org/wiki/RuleExecutionSemantics

http://blog.athico.com/2013/11/space-invaders-in-8-minutes-with-drools.html

Like Venus we will separate rules and their data sources, and the data sources are passed as arguments. So you’ll have a member var for the group, that can be passed as an argument, or injected at started. That looks like

DataSource<Person> persons.

Patterns have been split to separate data source selection and var assignment and constraints. All constraints now just go in a {….} expression block.

Person( age > 35 )

becomes

Person p from persons

{ p.age > 35 }

We may try to allow a default for the ‘from’, assuming the parser can handle this, as this can be inferred if there is a @Default on the DataSource. this will provide something close to DRL6

Person p { p.age > 35 }

However unlike DRL6 it’s more generic, so the {} does not have to come after the binding.

Person P

Restaurant r

{ p.location == “london”, r.food == “italian” }

We also want to bring in xpath like notation and support “deep facts”, where you can have reactivity over nested accessors.

Person p

p/banks{type == ‘current’}/account{ balance > 30}

The above would listener to change in the balance of a person’s current accounts, and react if they are over 30. Note you can have 1..n banks, it will filter collections like an xpath statement.

As well as simply filtering, the xpath notation could do assignment, so this will iterate and assign each current account to the bank var.

We also want to make it easier to re-use and extend our data flow, so we’ll support pluggable nodes and elements. You can think of this like a pluggable join, just that you control what you do with the input data and what you want to output to the child node.

We want to clean up our core engine network to make it usable outside of pure “production rules” environment. So this means separating the working memory, even separating the LHS and the RHS. So people can setup small dataflow for data input handlers, similar to functional reactive programming. So these data flows will become usable literals from java. So our LHS becomes a usable literal from java - this is inspired by our pojo rules work.

I’m also looking at a lighter and optimized code generated algorithm, to compliment phreak.