[mercury-users] Higher order programming

Ralph Becket rwab1 at cam.sri.com
Thu Apr 22 03:46:11 AEST 1999


> > 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?

Certainly.  The basic idea would be to provide things like the
following for the `obvious' candidates:

	:- func plus(int, int) = int.
	:- mode plus(in, in) = out.

	plus(X, Y) = X + Y.

and

	:- pred map(func(T1) = T2, list(T1), list(T2)).
	...

or even better

	:- func map(func(T1) = T2, list(T1)) = list(T2).
	...

and so forth.

> 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.

Absolutely.

> 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.

This will be very nice.  I agree with your assessment of your
priorities, though.

> 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 ;-)

I knew that was coming!  I'll see what I can do...

Cheers,

Ralph

-- 
Ralph Becket  |  rwab1 at cam.sri.com  |  http://www.cam.sri.com/people/becket.html



More information about the users mailing list