[m-dev.] higher order types, overloading
Ralph Becket
rafe at cs.mu.OZ.AU
Fri May 13 18:15:36 AEST 2005
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
--------------------------------------------------------------------------
More information about the developers
mailing list