[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