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

10 Oct 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  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
 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
 wrote:
On Tue, 9 Oct 2018 at 7:30 AM,  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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime