A question about run-time errors when class members are undefined

Anthony Clayden anthony_clayden at clear.net.nz
Mon Oct 8 23:02:45 UTC 2018


On Tue, 9 Oct 2018 at 7:30 AM, <camarao at dcc.ufmg.br> wrote:

Thanks Carlos. I wish I could say thank you for clarifying, but I'm afraid
this is as muddled as all the comments on the two proposals.

I don't want to go over it again. I just want to say that my suggestion
earlier in the thread is fundamentally different.

Em 2018-10-08 06:21, Anthony Clayden escreveu:
> > On Mon, 8 Oct 2018 at 8:41 PM, Simon Peyton Jones wrote:
> >


Strange: Simon's message has not appeared on the forum (he did send to it).
I've quoted it in full in my reply, but did break it into separate pieces.


>
> Global instance scope is not ok either: instances should be modular.


I just plain disagree. Fundamentally.


> >
> > Wadler & Blott's 1988 paper last paragraph had already explained: "But
> > there is no principal type! "
>
> There is always a principal type, for every expression.
> Of course the type depends on the context where the expression occurs.


Then it's not a _principal_ type for the expression, it's just a local type.
http://foldoc.org/principal

We arrive at the principal type by unifying the principal types of the
sub-expressions, down to the principal types of each atom. W&B are pointing
out that without global scope for instances, typing cannot assign a
principal type to each method. (They left that as an open problem at the
end of the paper. Haskell has resolved that problem by making all instances
global. Changing Haskell to modular instances would be a
breakage. Fundamentally.)

Under my suggestion, we can assign a (global) principal type to each method
-- indeed you must, by giving a signature very similar to a class
declaration; and that distinguishes overloaded functions from parametric
polymorphic functions.


AntC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20181009/33021c34/attachment.html>


More information about the Haskell-prime mailing list