[mercury-users] Question

[Fergus Henderson]

On 23-Aug-1999, Juergen Stuber <juergen at mpi-sb.mpg.de> wrote:
> Fergus Henderson <fjh at cs.mu.OZ.AU> writes:
> > > > But the compiler complains about the type of X not being func(A) = B.
> > > > Am I doing anything wrong? 
> > > 
> > > I think automatic currying doesn't apply here, so you have to
> > > do it explicitly.
> > 
> > That's correct.
> 
> After thinking a little bit more about it, I'm almost convinced
> that this is a bug.

It's not a bug.  That is, the design was deliberately chosen,
with a reasonable understanding of its implications, and the
implementation correctly implements that design; you may of course
disagree about whether or not it was a good design.

> The manual says:
> 
> 	You can also create higher-order function terms of
> 	non-zero arity and higher-order predicate terms by
> 	"currying", i.e. specifying the first few arguments to a
> 	predicate or function, but leaving the remaining arguments
> 	unspecified. For example, the unification
> 
> 	Sum123 = sum([1,2,3])
> 
> 	binds `Sum123' to a higher-order predicate term of type
> 	`pred(int)'. Similarly, the unification
> 
> 	Double = scalar_product(2)
> 
> 	binds `Double' to a higher-order function term of type
> 	`func(list(int)) = list(int)'.
>
> Why should `Double = scalar_product([2])' be handled differently
> from `FY = F(Y)' when `F' is a binary function?

There's two possible questions here.

One is a question about how the language reference manual
should be interpreted: should `Double = scalar_product([2])' be
handled differently from `FY = F(Y)' when `F' is a binary function,
and if so, which part of the language reference manual justifies this?
The language-lawyerly answer to that question is yes, they should
be treated differently.  The reason is that `FY = F(Y)' is parsed as
`FY = ''(F, Y)', which is another way of writing `FY = apply(F, Y)',
and here ''/N and apply/N are language builtins, not functions or predicates,
so the above paragraph quoted from the language reference manual does not
apply to them.

The other question is about the rationale for that language design choice:
why did we choose this design?  Why should the language be defined in a way
that causes `Double = scalar_product([2])' to be handled differently from
`FY = F(Y)' when `F' is a binary function?  The answer to this one is that
the former is easier to type than the latter.  The expression
`Double = scalar_product([2])' has a finite number of possible type
assignments (generally only one, unless some of the symbols involved
are overloaded), whereas if `FY = F(Y)' were allowed to supply only some
of `F's arguments, rather than all of them, then the expression `FY = F(Y)'
would have an infinite number of different possible type assignments.
Supporting that kind of thing would significantly complicate the type
checker.

-- 
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.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------