[mercury-users] Higher order programming

[Fergus Henderson]

On 21-Apr-1999, Ralph Becket <rwab1 at cam.sri.com> wrote:
> I'm a great advocate of higher-order programming, but I find that it's
> not as easy in Mercury as it ought to be,

Yes, I agree.  Regrettably higher-order programming in Mercury is not
quite as convenient as it is in some other languages, e.g. Haskell.
There's several reasons for this, some of which are technical, but
many of which are just historical.

> but more often because of library predicates not being
> provided in `forward only' versions or not taking `function' HO args.
...
> The problem, of course, is that the compiler doesn't like HO arguments
> that have multiple modes.  I'm sure this will be fixed in the fullness
> of time, but if that time is far away,

Yes, inferring the modes of HO argument terms is a somewhat tricky
technical problem -- not unsolvable, but difficult to solve in a
simple way -- and at the moment we have higher priorities, so I think
a solution to that problem is not likely to come along in the immediate
future.

> I wonder if the libraries could
> be extended to cover the obviously useful `forward' functions?  Maybe
> this would be a good job for a bored undergrad...

Could you elaborate on exactly what you're suggesting here?

> The other thing that's a pain is that many of the mapping and folding
> predicates only take HO pred's as args, rather than func's - func's
> are Good Things and their use is to be encouraged, says I!

I agree.

> This may be leading into a debate about how far it is desirable to mix
> predicate and functional styles.  Personally, I like the functional
> style in many situations where explicitly having to name an
> intermediate result is cumbersome.  One of the great attractions for
> me of functional languages is their brevity and clarity.

Yes.  My personal rule of thumb is that if a predicate's primary mode
is det and has one output argument, then in most cases it ought to be
defined as a function.

The Mercury library does not obey this design rule.  The reason is just
that until very recently we were still relying on the use of Prolog
implementations for debugging, which meant that we could not use functions.
The Mercury library also fails to make use of type classes and submodules,
again for similar historical reasons.

At some point we plan to create a new version of the standard library.
Version 2 will contain mostly the same functionality, but with a new
interface.  The intent is that it will be defined in submodules of a
single module (called e.g. `std'), and that it will make proper use of
functions and typeclasses.

However, redesigning the library interface from scratch is a fairly
big task (in particular the choice of appropriate type classes requires
very careful design), so I'm not sure when this will happen.  At the
moment I think our efforts are better focused on fixing a few rough
edges in the current implementation (e.g. making the Mercury C runtime
namespace-clean), implementating better environments (source-linked
debuggers, etc.), adding a few important language features (e.g.
existential types, compile-time garbage collection, etc.)
and working on better documentation that on starting work on version 2
of the standard library.

Still, I suppose in the mean time it would be pretty easy to add a few
simple things to version 1 of the standard library, and this might give
us much of the benefits.  In particular we could add function versions
(taking function arguments) of all the relevant higher-order predicates
in the library.

This will happen faster if someone sends us a patch for it, of course ;-)

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.