Prova Developers Blog

Annotations and guards are useful for any general purpose rules. Messaging and reaction rules are no exception. rules/reloaded/guard.prova now contains an additional example that shows how annotations and guards can be used to detect sequential event patterns. First, let's look at the client.

:- eval(client()). 

client() :- 
	% Send all the test messages from a separate thread
	switch_thread(),

	sendMsg(XID,task,0,request,login(user1,'10.10.10.10')),
	% Wait synchronously, could have waited asynchronously instead
	java.lang.Thread.sleep(500L),

The new update implements Prova guards on literals. Let's start with an example. Imagine that during unification, the target rule matches the source literal but we do not want to proceed with further evaluation unless a "guard" condition evaluates to true. The guards are specified in a syntax that is similar to the one used in Erlang (using brackets instead of the 'when' keyword) but the semantics are more appropriate for a rule language like Prova. See rules/reloaded/guard.prova and ProvaMetadataTest.java.

@author(dev1) r1(X):-q(X).
@author(dev22) r2(X):-q(X).

The old Prova version had an interesting but somewhat patchy approach to run-time processing of the rule metadata. The new rewrite is aiming to improve on this. The first question is what to annotate with metadata? It is clear that all Prova clauses (rules and facts) should be allowed to carry metadata. As you'll see below, I also annotate body literals so that whenever unification occurs, it uses metadata matching if metadata is present on the body literal.

The examples below are taken from a new test rules/reloaded/label.prova. This is the way metadata is added to rules:

State monad is perhaps the most widely known monad. The current literature on the State monad and monads in general seems to require a proliferation of syntactic constructs that the likes of the Haskell language use to represent these concepts. It is clear that there is unity (the category theory) behind all this and yet it does not seem to be as clear as it should be. Just consider this syntax from http://www.haskell.org/all_about_monads/html/statemonad.html

newtype State s a = State { runState :: (s -> (a,s)) } 
instance Monad (State s) where 

The Maybe monad is another classic functional programming construct. It has the purpose of wrapping the results of computations so that the error conditions are propagated as special Nothing objects. We model the Maybe monad by two terms maybe(nothing()) and maybe(just(X)). The latter actually represents a valid value.

The following code from the new test func_005.prova shows how we can build a monad using this representation.

% Demonstrate
%    the Maybe monad,
%    the use of monadic computations instead of monadic instances as inputs to bind,

Continuing on this drive to map the functional programming concepts to Prova. To open a little bracket here first, it is quite obvious that Erlang and Prova messaging look pretty close. I'll explore this subject later in more detail but it will suffice for now to note that Erlang obviously lacks logic programming elements. Let's see for now how some pretty cool elements of functional programming can be expressed in new Prova. I hope to demonstrate eventually how logic and functional programming as well as agents/workflows/events could be nicely integrated.

If you read the previous post, you probably asked yourselves a question, what happens if the predicates that represent functions are non-deterministic, i.e., return more than one possible value for a given set of arguments. As a result of this, combinator functions containing such mappings also become general mappings. Look at this new example func_002.prova:

% Demonstrate mappings that are not functions (based on non-deterministic values)

%%% use map to double the list elements POSSIBLY negating them: 8 solutions
:- solve(map([[plusminus,double],[1,2,3]],X)).

The new Subversion and binary distribution updates have a few simple additions that make writing functional programs far easier with Prova, including functions, function composition, currying, and typical high-order constructs like map, filter, or foldr.

Prova rewrite is progressing further with partitioned reactions and ESB messaging re-implementation. The updated Mule Prova Agents project now has all previous tests working against new Prova. Apart from small differences in Prova syntax, the most significant difference for ESB messaging is that Prova agents send and receive ProvaListImpl objects instead of now obsolete RMessage. Check it out here: https://mandarax.svn.sourceforge.net/svnroot/mandarax/mule-prova-agents2.... All tests beginning with the word Prova (for example, ProvaPetriDeferredChoiceTest) are using the Prova rewrite code.

I have updated the Mule Prova Agents project at https://mandarax.svn.sourceforge.net/svnroot/mandarax/mule-prova-agents2... and all tests run fine now. The project uses the latest build of Prova, Mule 2.1.2 and Drools 5.0.0.M5.

There are at least three ways Prova or Drools could be brought into the Mule world:

a) Mule transports,
b) Mule agents,
c) Mule components.