[mercury-users] Better syntax for currying and functions (was Re: Mercury syntax?

[Andrew Bromage]

G'day all.

You (Peter Moulder) wrote:

> Funny this should come up.  I just happened to be thinking today that
> data constructors are conceptually functions, so that
> 
>   :- type tree(T) ---> empty ; tree(tree(T), T, tree(T)).
> 
> is the same as declaring functions `tree__empty()' and
[Axioms deleted for brevity.]

Indeed, in functional languages, data constructors _are_ functions.

This came up in the Mercury group about a year ago, where I suggested
that data constructors should be exactly the same as functions, so that
you could do things like curry them and pass them as higher-order
arguments.  The alternative is for the user to wrap things up in the
appropriate lambda, which is clumsy and kinda hard to read but it works.

The implementation of constructors-as-functions straightforward, however
it has one BIG problem associated with it which makes it questionable
whether it's worth the implementation.

If you fail to supply the right number of arguments to a constructor
(very easy to do when you're adding a new field), you are going to get
errors of this form:

<<
 In clause for predicate `module:predicate/n':
   error: wrong number of arguments (11; should be 12)
   in use of constructor `lots_of_info'.
>>

It's hard to see why getting this kind of error message instead is worth
the change:

<<
 In clause for predicate `module:predicate/n':
   type error in unification of argument
   and functor `lots_of_info/12'.
   argument has type `(func(int) = (lots_of:lots_of_info))',
   functor `lots_of_info/12' has type 
   `lots_of_info(int, (tree234:tree234(int, (string:string))), ...
   /* Lots more */, int) :: (lots_of:lots_of_info)'.
>>

Unfortunately, getting functional language-like expressiveness buys you
functional language-like error reporting. :-)

Cheers,
Andrew Bromage