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

Wed Oct 10 18:55:45 UTC 2018

ok, cool! I'm not sure what modular scoping would look like, but it'd be
fun what that looks like!

I do think that the prime list isn't the best list though for figuring that
out / experimentations thereof :)

On Wed, Oct 10, 2018 at 1:36 PM <camarao at dcc.ufmg.br> wrote:

> Hi Carter,
>
> I am not proposing "local scoping". I think local scoping
> does not have substantial gains and at least introduces
> some difficulties and complexity (I have tried it in system CT).
>
> Even modular scope for instances is not mandatory, as I said.
> A general defaulting rule is a remedy, if instance modular scope is not
> supported, for changing the ambiguity rule
> (I prefer modular instance scoping though).
>
> I don't want to fight for anything. I'd like to contribute
> if the Haskell community friendly wishes me to do so in order to
> introduce MPTCs in a relatively simple way, without the need of extra
> mechanisms, based essentially on changing the ambiguity rule:
> I think a type like, say, (F a b, X a) => b is not ambiguous
> (F and X being classes with members f:: a->b and x::a, say),
> since then overloading of (f x) can be resolved, with a new
> ambiguity rule, depending on the context (or type) where (f x) is used.
>
> Kind regards,
>
> Carlos
>
> Em 2018-10-10 12:52, Carter Schonwald escreveu:
> > Carlos, local scoping for type classes is flat out not gonna happen in
> > the haskell language standard any time soon.
> >
> > 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
> >
> > merry adventures!
> > -Carter
> >
> > On Mon, Oct 8, 2018 at 8:47 PM Carlos Camarao
> > <carlos.camarao at gmail.com> wrote:
> >
> >> Hi.
> >>
> >>> 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.
> >>>
> >>>> Global instance scope is not ok either: instances should be
> >> modular.
> >>> I just plain disagree. Fundamentally.
> >>
> >> Global instance scope is not required for principal typing: a
> >> principal type is (just) a type of an expression in a given typing
> >> context that has all other types of this expression in that typing
> >> context as instances.
> >>
> >> (Also: instance modularity is not the central issue.)
> >>
> >>>>> 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
> >>
> >> A type system has the principal type property if, given a
> >> term and a typing context, there exists a type for this term in this
> >> typing context such that all other types for this term in this
> >> typing
> >> context are an instance of this type.
> >>
> >>> 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.
> >>
> >> A principal type theorem has been proved: see, for example, Theorem
> >> 1 in [1].
> >>
> >> Kind regards,
> >>
> >> Carlos
> >>
> >> [1] Ambiguity and Constrained Polymorphism,
> >> Carlos Camarão, Lucília Figueiredo, Rodrigo Ribeiro,
> >> Science of Computer Programming 124(1), 1--19, August 2016.
> >>
> >> On Mon, 8 Oct 2018 at 20:03, Anthony Clayden
> >> <anthony_clayden at clear.net.nz> wrote:
> >>
> >> 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 _______________________________________________
> >> Haskell-prime mailing list
> >> Haskell-prime at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
> >  _______________________________________________
> > Haskell-prime mailing list
> > Haskell-prime at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
> > _______________________________________________
> > Haskell-prime mailing list
> > Haskell-prime at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20181010/680c6cbd/attachment-0001.html>