[m-dev.] higher order types, overloading

[Ralph Becket]

Mark Brown, Friday, 13 May 2005:
> 
> The language design issue is that programs that make heavy use of this form
> of overloading, while they may be cute, are likely to be quite difficult to
> understand.  I'd be very much inclined to force users to avoid such
> overloading, or at least force them to use kind annotations, to avoid this
> problem.  IMHO this is not too much price to pay.

I have no problem with adding explicit kind annotations in the few
places I need them (will it be mainly instance declarations for type
classes using constructor classes?).

Overloading on arity is, I think, a real aid to program readability when
used appropriately.  I would be loath to forbid it (it would break heaps
of code).

> So, rather than implement the general solution mentioned above, here's
> what I propose.  The correct arity for a given type constructor should be
> found by attempting the following rules in the order given:
> 
> 	1) If there is an explicit kind annotation, use that to determine
> 	the arity of the type constructor.
> 
> 	2) If there is only one possible match, use that.
> 
> 	3) If there is an exact match (that is, if we have supplied N
> 	arguments and there is a symbol defined with N parameters), use
> 	that.  In other words, if we can give the type expression kind `*'
> 	then we do.
> 
> 	4) Report an ambiguity error, and suggest that the user use kind
> 	annotations to resolve it.  That is, if we have a choice between
> 	`* -> *' and `* -> * -> *', we don't favor either choice.

These rules look good to me.

> 	- As above, but leave out rule 3.  IMHO rule 3 should stay, since
> 	kind `*' would be by far and away the most common case, and would
> 	be what readers of the code would naturally expect when they see
> 	a type expression.
> 
> 	- As above, except that in rule 4 choose the simplest kind, for some
> 	value of "simplest".  For example, choose the kind with the shortest
> 	left-hand branch (that is, choose the arity which is closest to the
> 	number of arguments supplied).  IMHO, this would be giving users too
> 	much rope.
> 
> Any comments?

I agree with you in both cases.

-- Ralph
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------