Prova Developers Blog

I have talked about my views on functional programming and, specifically, the functional features in Prova to a number of people during the last year and it may be a good moment to share some ideas and directions. You may know my interests in systems that observe event streams and derive actionable information from raw data. Why am I not so excited about finite data and algebraic approaches offered by functional languages?

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.