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

Wed Oct 10 17:36:35 UTC 2018

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