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

camarao at dcc.ufmg.br camarao at dcc.ufmg.br
Mon Oct 8 18:20:20 UTC 2018


Em 2018-10-08 06:21, Anthony Clayden escreveu:
> On Mon, 8 Oct 2018 at 8:41 PM, Simon Peyton Jones wrote:
> 
>> You may be interested in Carlos Camarao’s interesting work.  For a
>> long time now he has advocated (in effect) making each function into
>> its own type class, rather that grouping them into classes.
> 
> No I think you're mis-apprehending. From the abstract to the group's
> SBLP2016 paper: "This depends on a modularization of instance
> visibility, as well as on a redefinition of Haskell’s ambiguity
> rule."

Hi. I wrote this to mean: "This depends *only* on modularization of
instances and a redefinition of Haskell's ambiguity rule" (i.e. no
extra mechanism is necessary and all well-typed Haskell programs
remain well-typed).

Haskell's ambiguity rule is not ok: a type is not ambiguous, it is an
expression that is ambiguous, depending on the context where it is
used.

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

> You might remember early last year Carlos submitted a proposal (in two
> rounds). Your comments were very relevant
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/48#issuecomment-287124007
> 
> Relevant because not just was it difficult to understand the proposal,
> the proposal had no answer to how instance resolution was to behave.
> "expression ambiguity" turned out to mean: use module scope to resolve
> overloading.

It is difficut until understanding how simple it really is.

The crucial notion of "expression ambiguity" is "overloading
resolution" (or: the decision of "overloading is resolved"), based on
the existence of "unreachable variables": if and only if there are
unreachable variables, satisfiability must be tested for the
constraints with unreachable variables.

Instance modular scope is secondary.

> In the second round of the proposal and in an extended email exchange
> off-forum with (I think it was) Rodrigo Ribeiro in Carlos' group I
> tried to tease out how module-scoped instances were going to work for
> a method exported to a module where there was a different instance in
> scope. Of course 'orphan instances' are the familiar symptom in GHC.
> 
> 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.

>> Perhaps that is in line with your thinking.
> 
> Not at all. My thinking is coming directly from Wadler's early 1988
> memo that I referenced (note *not* the W&B paper) + using some of
> GHC's more recent features like explicit type application in terms;
> and its counterpart: explicit method application in types.

Again: the proposal does not need any extra mechanism, just a change
to the ambiguity rule and instance modular scope. It would be possible
even to maintain instances as global, but in my view this
should not be done (it is better to have modular instances).

> I wonder how different would have been the history of Haskell if
> Wadler had not borrowed the terminology "class" and "method". Since
> Helium has a focus on Haskell learners/beginners: I wonder how much
> confusion we might have saved those coming from OOP where the terms
> mean something really quite different. We might have avoided "class"
> altogether; and talked of "overloaded function".

This is another matter, that does not need to be discussed now: we can
avoid type classes, or we can have type classes as optional, but this
discussion can be done later.

Kind regards,

Carlos


More information about the Haskell-prime mailing list