<div dir="ltr">Carlos, local scoping for type classes is flat out not gonna happen in the haskell language standard any time soon.<div><br></div><div>if you want to make a case for it, demonstrate its utility, this mailing list isn't for that. Especially for something that fundamentally changes the programming model of the language in question in a way that isn't compatible</div><div><br></div><div>merry adventures!</div><div>-Carter</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 8, 2018 at 8:47 PM Carlos Camarao <<a href="mailto:carlos.camarao@gmail.com">carlos.camarao@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi.<br><br>> Thanks Carlos. I wish I could say thank you for clarifying, but I'm<br>> afraid this is as muddled as all the comments on the two proposals.<br>><br>> I don't want to go over it again. I just want to say that my<br>> suggestion earlier in the thread is fundamentally different.<br>><br>>>    Global instance scope is not ok either: instances should be modular.<br>> I just plain disagree. Fundamentally.<br><br>Global instance scope is not required for principal typing: a<br>principal type is (just) a type of an expression in a given typing<br>context that has all other types of this expression in that typing<br>context as instances.<br><br>(Also: instance modularity is not the central issue.)<br><br>    >>> Wadler & Blott's 1988 paper last paragraph had already explained: "But<br>    >>> there is no principal type! "<br><br>    >> There is always a principal type, for every expression.<br>    >> Of course the type depends on the context where the expression occurs.<br><br>> Then it's not a _principal_ type for the expression, it's just a local type.<br>> <a href="http://foldoc.org/principal" target="_blank">http://foldoc.org/principal</a><br><br>A type system has the principal type property if, given a<br>term and a typing context, there exists a type for this term in this<br>typing context such that all other types for this term in this typing<br>context are an instance of this type.<br><br>> We arrive at the principal type by unifying the principal types of<br>> the sub-expressions, down to the principal types of each atom. W&B<br>> are pointing out that without global scope for instances, typing<br>> cannot assign a principal type to each method. (They left that as an<br>> open problem at the end of the paper. Haskell has resolved that<br>> problem by making all instances global. Changing Haskell to modular<br>> instances would be a breakage. Fundamentally.)<br>><br>> Under my suggestion, we can assign a (global) principal type to each<br>> method -- indeed you must, by giving a signature very similar to a<br>> class declaration; and that distinguishes overloaded functions from<br>> parametric polymorphic functions.<br><br>A principal type theorem has been proved: see, for example, Theorem 1 in [1].<br><br>Kind regards,<br><br>Carlos<br><br>[1] Ambiguity and Constrained Polymorphism,<br>    Carlos Camarão, Lucília Figueiredo, Rodrigo Ribeiro, <br>    Science of Computer Programming 124(1), 1--19, August 2016.<br><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 8 Oct 2018 at 20:03, Anthony Clayden <<a href="mailto:anthony_clayden@clear.net.nz" target="_blank">anthony_clayden@clear.net.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Tue, 9 Oct 2018 at 7:30 AM, <<a href="mailto:camarao@dcc.ufmg.br" target="_blank">camarao@dcc.ufmg.br</a>> wrote:<br></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">I don't want to go over it again. I just want to say that my suggestion earlier in the thread is fundamentally different.</div><div dir="auto"><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Em 2018-10-08 06:21, Anthony Clayden escreveu:<br>
> On Mon, 8 Oct 2018 at 8:41 PM, Simon Peyton Jones wrote:<br>
> </blockquote><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>
Global instance scope is not ok either: instances should be modular.</blockquote><div dir="auto"><br></div><div dir="auto">I just plain disagree. Fundamentally.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>> <br>
> Wadler & Blott's 1988 paper last paragraph had already explained: "But<br>
> there is no principal type! "<br>
<br>
There is always a principal type, for every expression.<br>
Of course the type depends on the context where the expression occurs.</blockquote><div dir="auto"><br></div><div dir="auto">Then it's not a _principal_ type for the expression, it's just a local type.</div><div dir="auto"><div><a href="http://foldoc.org/principal" target="_blank">http://foldoc.org/principal</a></div><br></div><div dir="auto">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.)</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">AntC</div></div></div>
_______________________________________________<br>
Haskell-prime mailing list<br>
<a href="mailto:Haskell-prime@haskell.org" target="_blank">Haskell-prime@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime</a><br>
</blockquote></div>
_______________________________________________<br>
Haskell-prime mailing list<br>
<a href="mailto:Haskell-prime@haskell.org" target="_blank">Haskell-prime@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime</a><br>
</blockquote></div>