On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote:

...

instance {-# OVERLAPPABLE #-} Show a => Show [a] where …

Is the syntax somewhat flexible in where the pragma can be placed? For example, some might prefer

{-# OVERLAPPING #-} instance Show [Char] where …

This variant may also be more convenient in cases where you need to CPP-guard that pragma, as it's on a separate line.

The current implementation requires the pragma exactly where showed it. I'm not keen on allowing it to be separated. I suppose with some more parser jiggery pokery it could be allowed immediately before (or, better, after). But cpp would let you say instance #if blah {-# OVERLAPPABLE #-} #endif Show a => Show [a] where ... Simon | -----Original Message----- | From: Johan Tibell [mailto:johan.tibell@gmail.com] | Sent: 29 July 2014 11:02 | To: Herbert Valerio Riedel | Cc: Niklas Hambüchen; Haskell Libraries (libraries@haskell.org); GHC | users; Simon Peyton Jones; ghc-devs | Subject: Re: Overlapping and incoherent instances | | On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel | wrote: | > On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote: | >>> instance {-# OVERLAPPABLE #-} Show a => Show [a] where … | >> | >> Is the syntax somewhat flexible in where the pragma can be placed? | >> For example, some might prefer | >> | >> {-# OVERLAPPING #-} | >> instance Show [Char] where … | > | > This variant may also be more convenient in cases where you need to | > CPP-guard that pragma, as it's on a separate line. | | Agreed, and if we remove the old pragma (even with a deprecation | cycle) you'll see quite a few of those as many library authors try to | have their libraries compile with the last 3 major GHC versions. | | P.S. For e.g. INLINABLE we require that you mention the function name | next to the pragma (which means that you can e.g. put the pragma after | the declaration). What's the rationale to not require | | {-# OVERLAPPING Show [Char] #-} | | here? Perhaps it's too annoying to have to repeat the types?

| One other issue this brings up: how does this all interact with -XSafe? | Right now, Safety can be inferred by looking at the set of LANGUAGE | pragmas and the import list. (Right?) With the change as implemented, | Safe inference would require looking at all instance declarations. Is | this OK? I'm honestly not sure, but I do know that, in the implementation, each instance declaration keeps track of (a) whether it is OVERLAPPABLE/OVERLAPPING/INCOHERENT, and (b) the setting of -XSafe in the module where the instance declaration is given. This doesn't change. So I can't answer your question directly, but I think that the behaviour is unchanged from that at present. Simon | | Richard | | On Jul 29, 2014, at 7:02 AM, Simon Peyton Jones | wrote: | | > The current implementation requires the pragma exactly where showed | it. | > | > I'm not keen on allowing it to be separated. | > | > I suppose with some more parser jiggery pokery it could be allowed | immediately before (or, better, after). | > | > But cpp would let you say | > | > instance | > #if blah | > {-# OVERLAPPABLE #-} | > #endif | > Show a => Show [a] where ... | > | > Simon | > | > | -----Original Message----- | > | From: Johan Tibell [mailto:johan.tibell@gmail.com] | > | Sent: 29 July 2014 11:02 | > | To: Herbert Valerio Riedel | > | Cc: Niklas Hambüchen; Haskell Libraries (libraries@haskell.org); | GHC | > | users; Simon Peyton Jones; ghc-devs | > | Subject: Re: Overlapping and incoherent instances | > | | > | On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel | > | | > | wrote: | > | > On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote: | > | >>> instance {-# OVERLAPPABLE #-} Show a => Show [a] where . | > | >> | > | >> Is the syntax somewhat flexible in where the pragma can be | placed? | > | >> For example, some might prefer | > | >> | > | >> {-# OVERLAPPING #-} | > | >> instance Show [Char] where . | > | > | > | > This variant may also be more convenient in cases where you need | > | > to CPP-guard that pragma, as it's on a separate line. | > | | > | Agreed, and if we remove the old pragma (even with a deprecation | > | cycle) you'll see quite a few of those as many library authors try | > | to have their libraries compile with the last 3 major GHC versions. | > | | > | P.S. For e.g. INLINABLE we require that you mention the function | > | name next to the pragma (which means that you can e.g. put the | > | pragma after the declaration). What's the rationale to not require | > | | > | {-# OVERLAPPING Show [Char] #-} | > | | > | here? Perhaps it's too annoying to have to repeat the types? | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users@haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | >

Am 29.07.2014 um 12:02 schrieb Johan Tibell:

P.S. For e.g. INLINABLE we require that you mention the function name next to the pragma (which means that you can e.g. put the pragma after the declaration). What's the rationale to not require

{-# OVERLAPPING Show [Char] #-}

here? Perhaps it's too annoying to have to repeat the types?

Once I proposed a pragma for documenting intentionally unimplemented instances. In this case there is no instance you can write a pragma in front of. Your OVERLAPPING syntax would be conform with the one of NOINSTANCE: https://ghc.haskell.org/trac/ghc/ticket/7775 Maybe NOINSTANCE can be reconsidered in the course of the introduction of the OVERLAP pragma?

Am 10.08.2014 um 22:12 schrieb Iavor Diatchki:

Hello,

Such a pragma sounds useful, and is very much like the "fails" instance from the "Instance chains" paper. You may also be interested in ticket #9334 (https://ghc.haskell.org/trac/ghc/ticket/9334), which proposes an alternative to overlapping instances, and I just updated it to point to #7775.

It seems to be one more step in the direction of freely programmable instance selection, that I have speculated about in the past: http://www.haskell.org/pipermail/libraries/2013-March/019533.html http://www.haskell.org/pipermail/libraries/2012-November/018831.html

On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel wrote:

+1. I like Niklas' syntax better. Also OVERLAPPABLE is a horrible word, OVERLAPPING sound less formidable (even though it might be slightly less accurrate).

We already get "overlap ok" in instance-related type errors, so OVERLAP_OK wouldn't be particularly alien even if it doesn't quite fit in with existing pragmas. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Or just OVERLAP (applying the razor). On 29.07.2014 17:56, Krzysztof Skrzętnicki wrote:

How about CAN_OVERLAP?

-- Krzysztof

29-07-2014 15:40, "Brandon Allbery" mailto:allbery.b@gmail.com> napisał(a):

On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel mailto:andreas.abel@ifi.lmu.de> wrote:

+1. I like Niklas' syntax better. Also OVERLAPPABLE is a horrible word, OVERLAPPING sound less formidable (even though it might be slightly less accurrate).

We already get "overlap ok" in instance-related type errors, so OVERLAP_OK wouldn't be particularly alien even if it doesn't quite fit in with existing pragmas.

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com mailto:allbery.b@gmail.com ballbery@sinenomine.net mailto:ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

CAN-OVERLAP and CAN-BE-OVERLAPPED are nice and clear. A little long, perhaps. On Tue, Jul 29, 2014 at 12:29 PM, Simon Peyton Jones wrote:

CAN_OVERLAP and CAN_BE_OVERLAPPED?

(instead of OVERLAPPING and OVERLAPPABLE)

Or CAN-OVERLAP, CAN-BE-OVERLAPPED

That’s ok with me if that’s what you all want!

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Krzysztof Skrzetnicki Sent: 29 July 2014 16:56 To: Brandon Allbery Cc: Simon Peyton Jones; Andreas Abel; GHC users; Haskell Libraries (libraries@haskell.org); ghc-devs

Subject: Re: Overlapping and incoherent instances

How about CAN_OVERLAP?

-- Krzysztof

29-07-2014 15:40, "Brandon Allbery" napisał(a):

On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel wrote:

+1. I like Niklas' syntax better. Also OVERLAPPABLE is a horrible word, OVERLAPPING sound less formidable (even though it might be slightly less accurrate).

We already get "overlap ok" in instance-related type errors, so OVERLAP_OK wouldn't be particularly alien even if it doesn't quite fit in with existing pragmas.

--

brandon s allbery kf8nh sine nomine associates

allbery.b@gmail.com ballbery@sinenomine.net

unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Hello, I have no strong feelings about what words we use, but I wanted to point out that while we are thinking of names, we may want to consider 3 (and not just 2). Currently we have: * OVERLAPPING: This instances may overlap existing instances * OVERLAPPABLE: This instance may be overlapped by existing instances * OVERLAPS: This instance is both OVERLAPPING and OVERLAPPABLE Of course, the 3rd one (OVERLAPS) could be replaced by a comma separated list of the first two, but I could not see how to make this work easily with GHC's pragmas. It would not be hard to simply allow 2 pragmas after the `instance` keyword, but both of those seem rather long. Either way, I'll keep an eye on the discussion, and would be happy to change the names if a consesus is reached. -Iavor On Tue, Jul 29, 2014 at 9:57 AM, David Thomas wrote:

Honestly, I think "OVERLAPS" and "OVERLAPPED" are perfectly clear.

...

CAN-OVERLAP and CAN-BE-OVERLAPPED are nice and clear. A little long,

On Tue, Jul 29, 2014 at 9:52 AM, David Feuer wrote: perhaps.

...

On Tue, Jul 29, 2014 at 12:29 PM, Simon Peyton Jones wrote:

...

CAN_OVERLAP and CAN_BE_OVERLAPPED?

(instead of OVERLAPPING and OVERLAPPABLE)

Or CAN-OVERLAP, CAN-BE-OVERLAPPED

That’s ok with me if that’s what you all want!

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of

Krzysztof

...

...

Skrzetnicki Sent: 29 July 2014 16:56 To: Brandon Allbery Cc: Simon Peyton Jones; Andreas Abel; GHC users; Haskell Libraries (libraries@haskell.org); ghc-devs

Subject: Re: Overlapping and incoherent instances

How about CAN_OVERLAP?

-- Krzysztof

29-07-2014 15:40, "Brandon Allbery" napisał(a):

On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel wrote:

+1. I like Niklas' syntax better. Also OVERLAPPABLE is a horrible word, OVERLAPPING sound less formidable (even though it might be slightly less accurrate).

We already get "overlap ok" in instance-related type errors, so OVERLAP_OK wouldn't be particularly alien even if it doesn't quite fit in with existing pragmas.

--

brandon s allbery kf8nh sine nomine associates

allbery.b@gmail.com ballbery@sinenomine.net

unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Iavor, I am a bit surprised by the distinction you outline below. This is maybe because I am native German, not English. The German equivalent of "overlap", "überschneiden/überlappen", is used exclusively in a symmetrical fashion. It's like in English, if I say "our interests overlap", then it is pointless to ask whether my interest are overlapping yours or are overlapped by yours. I want to alert you to the fact that non-native English speaker might have little understanding for a distinction between "OVERLAPPING" and "OVERLAPPABLE". Let's try to guess what it meant: Given A) instance Bla Char B) instance Bla a => Bla [a] C) instance Bla String you will in context A,B write C as OVERLAPPING, and in context A,C write B as OVERLAPPABLE? Is this correct? Is it important to distinguish between OVERLAPPING and OVERLAPPABLE? Why? -- Andreas On 29.07.2014 19:28, Iavor Diatchki wrote:

Hello,

I have no strong feelings about what words we use, but I wanted to point out that while we are thinking of names, we may want to consider 3 (and not just 2). Currently we have: * OVERLAPPING: This instances may overlap existing instances * OVERLAPPABLE: This instance may be overlapped by existing instances * OVERLAPS: This instance is both OVERLAPPING and OVERLAPPABLE

Of course, the 3rd one (OVERLAPS) could be replaced by a comma separated list of the first two, but I could not see how to make this work easily with GHC's pragmas. It would not be hard to simply allow 2 pragmas after the `instance` keyword, but both of those seem rather long.

Either way, I'll keep an eye on the discussion, and would be happy to change the names if a consesus is reached.

-Iavor

On Tue, Jul 29, 2014 at 9:57 AM, David Thomas mailto:davidleothomas@gmail.com> wrote:

Honestly, I think "OVERLAPS" and "OVERLAPPED" are perfectly clear.

On Tue, Jul 29, 2014 at 9:52 AM, David Feuer mailto:david.feuer@gmail.com> wrote: > CAN-OVERLAP and CAN-BE-OVERLAPPED are nice and clear. A little long, perhaps. > > On Tue, Jul 29, 2014 at 12:29 PM, Simon Peyton Jones > mailto:simonpj@microsoft.com> wrote: >> CAN_OVERLAP and CAN_BE_OVERLAPPED? >> >> >> >> (instead of OVERLAPPING and OVERLAPPABLE) >> >> >> >> Or CAN-OVERLAP, CAN-BE-OVERLAPPED >> >> >> >> That’s ok with me if that’s what you all want! >> >> >> >> Simon >> >> >> >> From: Glasgow-haskell-users >> [mailto:glasgow-haskell-users-bounces@haskell.org mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Krzysztof >> Skrzetnicki >> Sent: 29 July 2014 16:56 >> To: Brandon Allbery >> Cc: Simon Peyton Jones; Andreas Abel; GHC users; Haskell Libraries >> (libraries@haskell.org mailto:libraries@haskell.org); ghc-devs >> >> >> Subject: Re: Overlapping and incoherent instances >> >> >> >> How about CAN_OVERLAP? >> >> -- >> Krzysztof >> >> 29-07-2014 15:40, "Brandon Allbery" mailto:allbery.b@gmail.com> napisał(a): >> >> On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel mailto:andreas.abel@ifi.lmu.de> >> wrote: >> >> +1. I like Niklas' syntax better. Also OVERLAPPABLE is a horrible word, >> OVERLAPPING sound less formidable (even though it might be slightly less >> accurrate). >> >> >> >> We already get "overlap ok" in instance-related type errors, so OVERLAP_OK >> wouldn't be particularly alien even if it doesn't quite fit in with existing >> pragmas. >> >> >> >> -- >> >> brandon s allbery kf8nh sine nomine associates >> >> allbery.b@gmail.com mailto:allbery.b@gmail.com ballbery@sinenomine.net mailto:ballbery@sinenomine.net >> >> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries@haskell.org mailto:Libraries@haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries@haskell.org mailto:Libraries@haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries@haskell.org mailto:Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

On Wed, Jul 30, 2014 at 2:50 PM, Ivan Lazar Miljenovic wrote:

On 30 July 2014 22:07, Andreas Abel wrote:

...

I am a bit surprised by the distinction you outline below. This is maybe because I am native German, not English. The German equivalent of "overlap", "überschneiden/überlappen", is used exclusively in a symmetrical fashion. It's like in English, if I say "our interests overlap", then it is pointless to ask whether my interest are overlapping yours or are overlapped by yours. I want to alert you to the fact that non-native English speaker might have little understanding for a distinction between "OVERLAPPING" and "OVERLAPPABLE".

Let's try to guess what it meant: Given

A) instance Bla Char B) instance Bla a => Bla [a] C) instance Bla String

you will in context A,B write C as OVERLAPPING, and in context A,C write B as OVERLAPPABLE?

IIUC, B will be OVERLAPPABLE ("you can overlap this") and C will be OVERLAPPING ("I'm overlapping an existing one") whereas C will be plain.

Apologies if this question doesn't make sense. Can we really talk about overlapping, given that instances can be written in different modules, moved between modules, or removed?

Andreas, remember that GHC 7.8 already implements (essentially) the same algorithm. The difference is that 7.8 offers only the brutal -XOverlappingInstances to control it. In your example of the decision you make when writing instance Bla a => Bla [a] vs instance {-# OVERLAPPABLE #-} Bla a => Bla [a] you are, with GHC 7.8, making precisely the same decision when you decide whether or not to add {-# LANGUAGE OverlappingInstances #-} to that module. Perhaps that wasn't clear in what I wrote; apologies. So your proposal seems to be this don't remove -XOverlappingInstances, because that will prevent programmers from "flipping on/off pragmas until their program goes through". It's hard to argue AGAINST providing the opportunity for more careful programmers to express their intentions more precisely, which is what the OVERLAP/OVERLAPPABLE pragmas do. Concerning deprecating OverlappingInstances, my gut feel is that it is positively a good thing to guide programmers towards a more robust programming style. But my reason for starting this thread was to see whether or not others' gut feel is similar. Simon | -----Original Message----- | From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of | Andreas Abel | Sent: 31 July 2014 08:59 | To: Simon Peyton Jones; ghc-devs; GHC users; Haskell Libraries | (libraries@haskell.org) | Subject: Re: Overlapping and incoherent instances | | On 31.07.2014 09:20, Simon Peyton Jones wrote: | > Friends, in sending my message below, I should also have sent a link | > to | > | > https://ghc.haskell.org/trac/ghc/ticket/9242#comment:25 | | Indeed. | | Quoting from the spec: | | * Eliminate any candidate IX for which both of the following hold: | * There is another candidate IY that is strictly more specific; | that is, IY is a substitution instance of IX but not vice versa. | | * Either IX is overlappable or IY is overlapping. | | Mathematically, this makes a lot of sense. But put on the hat of | library writers, and users, and users that don't rtfm. Looking out | from under this hat, the one may always wonder whether one should make | one's generic instances OVERLAPPABLE or not. | | If I create a library with type class Bla and | | instance Bla a => Bla [a] | | I could be a nice library writer and spare my users from declaring | their Bla String instances as OVERLAPPING, so I'd write | | instance {-# OVERLAPPABLE #-} Bla a => Bla [a] | | Or maybe that would be malicious? | | I think the current proposal is too sophisticated. There are no | convincing examples given in the discussion so far that demonstrate | where this sophistication pays off in practice. | | Keep in mind that 99% of the Haskell users will never study the | instance resolution algorithm or its specification, but just flip | on/off pragmas until their code goes through. [At least that was my | approach: whenever GHC asks for one more LANGUAGE pragma, just throw it | in.] | | Cheers, | Andreas | | | > Comment 25 describes the semantics of OVERLAPPING/OVERLAPPABLE etc, | > which I signally failed to do in my message below, leading to | > confusion in the follow up messages. My apologies for that. | > | > Some key points: | > | > *There is a useful distinction between /overlapping/ and | > /overlappable/, but if you don't want to be bothered with it you can | > just say OVERLAPS (which means both). | > | > *Overlap between two candidate instances is allowed if /either/ has | > the relevant property. This is a bit sloppy, but reduces the | > annotation burden. Actually, with this per-instance stuff I think | > it'd be perfectly defensible to require both to be annotated, but | > that's a different discussion. | > | > I hope that helps clarify. | > | > I'm really pretty certain that the basic proposal here is good: it | > implements the current semantics in a more fine-grained manner. My | > main motivation was to signal the proposed deprecation of the global | > per-module flag -XoverlappingInstances. Happily people generally | seem | > fine with this. It is, after all, precisely what deprecations are | for | > ("the old thing still works for now, but it won't do so for ever, and | > you should change as soon as is convenient"). | > | > Thanks | > | > Simon | > | > *From:*Libraries [mailto:libraries-bounces@haskell.org] *On Behalf Of | > *Simon Peyton Jones | > *Sent:* 29 July 2014 10:11 | > *To:* ghc-devs; GHC users; Haskell Libraries (libraries@haskell.org) | > *Subject:* Overlapping and incoherent instances | > | > Friends | > | > One of GHC's more widely-used features is overlapping (and sometimes | > incoherent) instances. The user-manual documentation is here | > <http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- | extensions.html#instance-overlap>. | > | > The use of overlapping/incoherent instances is controlled by LANGUAGE | > pragmas: OverlappingInstances and IncoherentInstances respectively. | > | > However the overlap/incoherent-ness is a property of the **instance | > declaration** itself, and has been for a long time. Using LANGUAGE | > OverlappingInstances simply sets the "I am an overlapping instance" | > flag for every instance declaration in that module. | > | > This is a Big Hammer. It give no clue about **which** particular | > instances the programmer is expecting to be overlapped, nor which are | > doing the overlapping. It brutally applies to every instance in | the | > module. Moreover, when looking at an instance declaration, there is | > no nearby clue that it might be overlapped. The clue might be in the | > command line that compiles that module! | > | > Iavor has recently implemented per-instance-declaration pragmas, so | > you can say | > | > instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... | > | > instance {-# OVERLAPPING #-} Show [Char] where ... | > | > This is much more precise (it affects only those specific instances) | > and it is much clearer (you see it when you see the instance | declaration). | > | > This new feature will be in GHC 7.10 and I'm sure you will be happy | > about that. *But I propose also to deprecate the LANGUAGE pragmas | > OverlappingInstances and IncoherentInstances*, as way to encourage | > everyone to use the new feature instead of the old big hammer. The | > old LANGUAGE pragmas will continue to work, of course, for at least | > another complete release cycle. We could make that two cycles if it | was helpful. | > | > However, if you want deprecation-free libraries, it will entail a | wave | > of library updates. | > | > This email is just to warn you, and to let you yell if you think this | is | > a bad idea. It would actually not be difficult to retain the old | > LANGUAGE pragmas indefinitely - it just seems wrong not to actively | > push authors in the right direction. | > | > These deprecations of course popped up in the test suite, so I've | been | > replacing them with per-instance pragmas there too. Interestingly in | > some cases, when looking for which instances needed the pragmas, I | > found...none. So OverlappingInstances was entirely unnecessary. Maybe | > library authors will find that too! | > | > Simon | > | > | > | > _______________________________________________ | > Libraries mailing list | > Libraries@haskell.org | > http://www.haskell.org/mailman/listinfo/libraries | > | | | -- | Andreas Abel <>< Du bist der geliebte Mensch. | | Department of Computer Science and Engineering Chalmers and Gothenburg | University, Sweden | | andreas.abel@gu.se | http://www2.tcs.ifi.lmu.de/~abel/ | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries

Ah, no, I do not want to argue against a more fine-grained control of overlapping instances. I only argue against the extra sophistication that a distinction of OVERLAPPABLE vs. OVERLAPPING brings. As I understood, declaring a generic instance OVERLAPPABLE allows other more specific instances to be OVERLAPPING without having to declare this. And it allows to declare a generic instance even if there are specific instances already it would overlap with. My proposal is to have just one pragma, e.g. OVERLAP, that allows overlap in either direction. But if you have examples whether the extra sophistication introduced by a separation into OVERLAPPABLE and OVERLAPPING is needed, I am happy to go along... On 31.07.2014 10:13, Simon Peyton Jones wrote:

Andreas, remember that GHC 7.8 already implements (essentially) the same algorithm. The difference is that 7.8 offers only the brutal -XOverlappingInstances to control it. In your example of the decision you make when writing instance Bla a => Bla [a] vs instance {-# OVERLAPPABLE #-} Bla a => Bla [a] you are, with GHC 7.8, making precisely the same decision when you decide whether or not to add {-# LANGUAGE OverlappingInstances #-} to that module. Perhaps that wasn't clear in what I wrote; apologies.

So your proposal seems to be this

don't remove -XOverlappingInstances, because that will prevent programmers from "flipping on/off pragmas until their program goes through".

It's hard to argue AGAINST providing the opportunity for more careful programmers to express their intentions more precisely, which is what the OVERLAP/OVERLAPPABLE pragmas do.

Concerning deprecating OverlappingInstances, my gut feel is that it is positively a good thing to guide programmers towards a more robust programming style. But my reason for starting this thread was to see whether or not others' gut feel is similar.

Simon

| -----Original Message----- | From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of | Andreas Abel | Sent: 31 July 2014 08:59 | To: Simon Peyton Jones; ghc-devs; GHC users; Haskell Libraries | (libraries@haskell.org) | Subject: Re: Overlapping and incoherent instances | | On 31.07.2014 09:20, Simon Peyton Jones wrote: | > Friends, in sending my message below, I should also have sent a link | > to | > | > https://ghc.haskell.org/trac/ghc/ticket/9242#comment:25 | | Indeed. | | Quoting from the spec: | | * Eliminate any candidate IX for which both of the following hold: | * There is another candidate IY that is strictly more specific; | that is, IY is a substitution instance of IX but not vice versa. | | * Either IX is overlappable or IY is overlapping. | | Mathematically, this makes a lot of sense. But put on the hat of | library writers, and users, and users that don't rtfm. Looking out | from under this hat, the one may always wonder whether one should make | one's generic instances OVERLAPPABLE or not. | | If I create a library with type class Bla and | | instance Bla a => Bla [a] | | I could be a nice library writer and spare my users from declaring | their Bla String instances as OVERLAPPING, so I'd write | | instance {-# OVERLAPPABLE #-} Bla a => Bla [a] | | Or maybe that would be malicious? | | I think the current proposal is too sophisticated. There are no | convincing examples given in the discussion so far that demonstrate | where this sophistication pays off in practice. | | Keep in mind that 99% of the Haskell users will never study the | instance resolution algorithm or its specification, but just flip | on/off pragmas until their code goes through. [At least that was my | approach: whenever GHC asks for one more LANGUAGE pragma, just throw it | in.] | | Cheers, | Andreas | | | > Comment 25 describes the semantics of OVERLAPPING/OVERLAPPABLE etc, | > which I signally failed to do in my message below, leading to | > confusion in the follow up messages. My apologies for that. | > | > Some key points: | > | > *There is a useful distinction between /overlapping/ and | > /overlappable/, but if you don't want to be bothered with it you can | > just say OVERLAPS (which means both). | > | > *Overlap between two candidate instances is allowed if /either/ has | > the relevant property. This is a bit sloppy, but reduces the | > annotation burden. Actually, with this per-instance stuff I think | > it'd be perfectly defensible to require both to be annotated, but | > that's a different discussion. | > | > I hope that helps clarify. | > | > I'm really pretty certain that the basic proposal here is good: it | > implements the current semantics in a more fine-grained manner. My | > main motivation was to signal the proposed deprecation of the global | > per-module flag -XoverlappingInstances. Happily people generally | seem | > fine with this. It is, after all, precisely what deprecations are | for | > ("the old thing still works for now, but it won't do so for ever, and | > you should change as soon as is convenient"). | > | > Thanks | > | > Simon | > | > *From:*Libraries [mailto:libraries-bounces@haskell.org] *On Behalf Of | > *Simon Peyton Jones | > *Sent:* 29 July 2014 10:11 | > *To:* ghc-devs; GHC users; Haskell Libraries (libraries@haskell.org) | > *Subject:* Overlapping and incoherent instances | > | > Friends | > | > One of GHC's more widely-used features is overlapping (and sometimes | > incoherent) instances. The user-manual documentation is here | > <http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- | extensions.html#instance-overlap>. | > | > The use of overlapping/incoherent instances is controlled by LANGUAGE | > pragmas: OverlappingInstances and IncoherentInstances respectively. | > | > However the overlap/incoherent-ness is a property of the **instance | > declaration** itself, and has been for a long time. Using LANGUAGE | > OverlappingInstances simply sets the "I am an overlapping instance" | > flag for every instance declaration in that module. | > | > This is a Big Hammer. It give no clue about **which** particular | > instances the programmer is expecting to be overlapped, nor which are | > doing the overlapping. It brutally applies to every instance in | the | > module. Moreover, when looking at an instance declaration, there is | > no nearby clue that it might be overlapped. The clue might be in the | > command line that compiles that module! | > | > Iavor has recently implemented per-instance-declaration pragmas, so | > you can say | > | > instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... | > | > instance {-# OVERLAPPING #-} Show [Char] where ... | > | > This is much more precise (it affects only those specific instances) | > and it is much clearer (you see it when you see the instance | declaration). | > | > This new feature will be in GHC 7.10 and I'm sure you will be happy | > about that. *But I propose also to deprecate the LANGUAGE pragmas | > OverlappingInstances and IncoherentInstances*, as way to encourage | > everyone to use the new feature instead of the old big hammer. The | > old LANGUAGE pragmas will continue to work, of course, for at least | > another complete release cycle. We could make that two cycles if it | was helpful. | > | > However, if you want deprecation-free libraries, it will entail a | wave | > of library updates. | > | > This email is just to warn you, and to let you yell if you think this | is | > a bad idea. It would actually not be difficult to retain the old | > LANGUAGE pragmas indefinitely - it just seems wrong not to actively | > push authors in the right direction. | > | > These deprecations of course popped up in the test suite, so I've | been | > replacing them with per-instance pragmas there too. Interestingly in | > some cases, when looking for which instances needed the pragmas, I | > found...none. So OverlappingInstances was entirely unnecessary. Maybe | > library authors will find that too! | > | > Simon | > | > | > | > _______________________________________________ | > Libraries mailing list | > Libraries@haskell.org | > http://www.haskell.org/mailman/listinfo/libraries | > | | | -- | Andreas Abel <>< Du bist der geliebte Mensch. | | Department of Computer Science and Engineering Chalmers and Gothenburg | University, Sweden | | andreas.abel@gu.se | http://www2.tcs.ifi.lmu.de/~abel/ | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

Right, I see. The dummy version is to use just the symmetric OVERLAPS whenever the compiler complains. I can very well live with that. The split into OVERLAPPABLE and OVERLAPPING is for those that dig deeper. Content :), Andreas On 31.07.2014 13:02, Simon Peyton Jones wrote:

| My proposal is to have just one pragma, e.g. OVERLAP, that allows | overlap in either direction. But if you have examples whether the | extra sophistication introduced by a separation into OVERLAPPABLE and | OVERLAPPING is needed, I am happy to go along...

Great! As you'll see the proposal, "OVERLAPS" is precisely what you want. I don't care whether it is called "OVERLAP" or "OVERLAPS".

So it sounds as if you are content. (I assume you don't want to *prevent* careful programmers from saying something more precise.)

Simon

| | On 31.07.2014 10:13, Simon Peyton Jones wrote: | > Andreas, remember that GHC 7.8 already implements (essentially) the | same algorithm. The difference is that 7.8 offers only the brutal - | XOverlappingInstances to control it. In your example of the decision | you make when writing | > instance Bla a => Bla [a] | > vs | > instance {-# OVERLAPPABLE #-} Bla a => Bla [a] you are, with GHC | > 7.8, making precisely the same decision when you decide whether or | not to add {-# LANGUAGE OverlappingInstances #-} to that module. | Perhaps that wasn't clear in what I wrote; apologies. | > | > So your proposal seems to be this | > | > don't remove -XOverlappingInstances, because that will prevent | > programmers from "flipping on/off pragmas until their program | > goes through". | > | > It's hard to argue AGAINST providing the opportunity for more careful | programmers to express their intentions more precisely, which is what | the OVERLAP/OVERLAPPABLE pragmas do. | > | > Concerning deprecating OverlappingInstances, my gut feel is that it | is positively a good thing to guide programmers towards a more robust | programming style. But my reason for starting this thread was to see | whether or not others' gut feel is similar. | > | > Simon | > | > | -----Original Message----- | > | From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of | > | Andreas Abel | > | Sent: 31 July 2014 08:59 | > | To: Simon Peyton Jones; ghc-devs; GHC users; Haskell Libraries | > | (libraries@haskell.org) | > | Subject: Re: Overlapping and incoherent instances | > | | > | On 31.07.2014 09:20, Simon Peyton Jones wrote: | > | > Friends, in sending my message below, I should also have sent a | > | > link to | > | > | > | > https://ghc.haskell.org/trac/ghc/ticket/9242#comment:25 | > | | > | Indeed. | > | | > | Quoting from the spec: | > | | > | * Eliminate any candidate IX for which both of the following | hold: | > | * There is another candidate IY that is strictly more specific; | > | that is, IY is a substitution instance of IX but not vice | versa. | > | | > | * Either IX is overlappable or IY is overlapping. | > | | > | Mathematically, this makes a lot of sense. But put on the hat of | > | library writers, and users, and users that don't rtfm. Looking out | > | from under this hat, the one may always wonder whether one should | > | make one's generic instances OVERLAPPABLE or not. | > | | > | If I create a library with type class Bla and | > | | > | instance Bla a => Bla [a] | > | | > | I could be a nice library writer and spare my users from declaring | > | their Bla String instances as OVERLAPPING, so I'd write | > | | > | instance {-# OVERLAPPABLE #-} Bla a => Bla [a] | > | | > | Or maybe that would be malicious? | > | | > | I think the current proposal is too sophisticated. There are no | > | convincing examples given in the discussion so far that demonstrate | > | where this sophistication pays off in practice. | > | | > | Keep in mind that 99% of the Haskell users will never study the | > | instance resolution algorithm or its specification, but just flip | > | on/off pragmas until their code goes through. [At least that was | my | > | approach: whenever GHC asks for one more LANGUAGE pragma, just | throw | > | it in.] | > | | > | Cheers, | > | Andreas | > | | > | | > | > Comment 25 describes the semantics of OVERLAPPING/OVERLAPPABLE | > | > etc, which I signally failed to do in my message below, leading | to | > | > confusion in the follow up messages. My apologies for that. | > | > | > | > Some key points: | > | > | > | > *There is a useful distinction between /overlapping/ and | > | > /overlappable/, but if you don't want to be bothered with it you | > | > can just say OVERLAPS (which means both). | > | > | > | > *Overlap between two candidate instances is allowed if /either/ | > | > has the relevant property. This is a bit sloppy, but reduces the | > | > annotation burden. Actually, with this per-instance stuff I | think | > | > it'd be perfectly defensible to require both to be annotated, but | > | > that's a different discussion. | > | > | > | > I hope that helps clarify. | > | > | > | > I'm really pretty certain that the basic proposal here is good: | it | > | > implements the current semantics in a more fine-grained manner. | > | > My main motivation was to signal the proposed deprecation of the | > | > global per-module flag -XoverlappingInstances. Happily people | > | > generally | > | seem | > | > fine with this. It is, after all, precisely what deprecations | are | > | for | > | > ("the old thing still works for now, but it won't do so for ever, | > | > and you should change as soon as is convenient"). | > | > | > | > Thanks | > | > | > | > Simon | > | > | > | > *From:*Libraries [mailto:libraries-bounces@haskell.org] *On | Behalf | > | > Of *Simon Peyton Jones | > | > *Sent:* 29 July 2014 10:11 | > | > *To:* ghc-devs; GHC users; Haskell Libraries | > | > (libraries@haskell.org) | > | > *Subject:* Overlapping and incoherent instances | > | > | > | > Friends | > | > | > | > One of GHC's more widely-used features is overlapping (and | > | > sometimes | > | > incoherent) instances. The user-manual documentation is here | > | > <http://www.haskell.org/ghc/docs/latest/html/users_guide/type- | clas | > | > s- | > | extensions.html#instance-overlap>. | > | > | > | > The use of overlapping/incoherent instances is controlled by | > | > LANGUAGE | > | > pragmas: OverlappingInstances and IncoherentInstances | respectively. | > | > | > | > However the overlap/incoherent-ness is a property of the | > | > **instance | > | > declaration** itself, and has been for a long time. Using | > | > LANGUAGE OverlappingInstances simply sets the "I am an | overlapping instance" | > | > flag for every instance declaration in that module. | > | > | > | > This is a Big Hammer. It give no clue about **which** particular | > | > instances the programmer is expecting to be overlapped, nor which | are | > | > doing the overlapping. It brutally applies to every instance | in | > | the | > | > module. Moreover, when looking at an instance declaration, there | > | > is no nearby clue that it might be overlapped. The clue might be | > | > in the command line that compiles that module! | > | > | > | > Iavor has recently implemented per-instance-declaration pragmas, | > | > so you can say | > | > | > | > instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... | > | > | > | > instance {-# OVERLAPPING #-} Show [Char] where ... | > | > | > | > This is much more precise (it affects only those specific | > | > instances) and it is much clearer (you see it when you see the | > | > instance | > | declaration). | > | > | > | > This new feature will be in GHC 7.10 and I'm sure you will be | > | > happy about that. *But I propose also to deprecate the LANGUAGE | > | > pragmas OverlappingInstances and IncoherentInstances*, as way to | > | > encourage everyone to use the new feature instead of the old big | > | > hammer. The old LANGUAGE pragmas will continue to work, of | > | > course, for at least another complete release cycle. We could | > | > make that two cycles if it | > | was helpful. | > | > | > | > However, if you want deprecation-free libraries, it will entail a | > | wave | > | > of library updates. | > | > | > | > This email is just to warn you, and to let you yell if you think | > | > this | > | is | > | > a bad idea. It would actually not be difficult to retain the | old | > | > LANGUAGE pragmas indefinitely - it just seems wrong not to | > | > actively push authors in the right direction. | > | > | > | > These deprecations of course popped up in the test suite, so I've | > | been | > | > replacing them with per-instance pragmas there too. | Interestingly | > | > in some cases, when looking for which instances needed the | > | > pragmas, I found...none. So OverlappingInstances was entirely | > | > unnecessary. Maybe library authors will find that too! | > | > | > | > Simon | > | > | > | > | > | > | > | > _______________________________________________ | > | > Libraries mailing list | > | > Libraries@haskell.org | > | > http://www.haskell.org/mailman/listinfo/libraries | > | > | > | | > | | > | -- | > | Andreas Abel <>< Du bist der geliebte Mensch. | > | | > | Department of Computer Science and Engineering Chalmers and | > | Gothenburg University, Sweden | > | | > | andreas.abel@gu.se | > | http://www2.tcs.ifi.lmu.de/~abel/ | > | _______________________________________________ | > | Libraries mailing list | > | Libraries@haskell.org | > | http://www.haskell.org/mailman/listinfo/libraries | > _______________________________________________ | > Libraries mailing list | > Libraries@haskell.org | > http://www.haskell.org/mailman/listinfo/libraries | > | | | -- | Andreas Abel <>< Du bist der geliebte Mensch. | | Department of Computer Science and Engineering Chalmers and Gothenburg | University, Sweden | | andreas.abel@gu.se | http://www2.tcs.ifi.lmu.de/~abel/ _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

On Mon, Aug 11, 2014 at 11:36 AM, Twan van Laarhoven wrote:

To me, perhaps naively, IncoherentInstances is way more scary than OverlappingInstances.

​It might be a bit naive. Most things that incoherent instances would allow are allowed with overlapping instances so long as you partition your code into two modules. So unless such a partitioning is impossible, overlapping instances are almost as scary as incoherent instances (unless the module separation somehow makes it less scary). And actually, with the way GHC handles instances, you can get more incoherent behavior than incoherent instances allow without enabling any extensions, just using modules: module A where class Foo a where foo :: a module B where import A instance F​ ​oo Int where foo = 5 bar :: Int ; bar = foo module C where import A instance Foo Int where foo = 6 baz :: Int ; baz = foo module D where import B import C quux = bar + baz -- 11​ ​ -- ​ Dan​

This has been reported: https://ghc.haskell.org/trac/ghc/ticket/8338 But it's really not clear what the solution is! Richard On Aug 11, 2014, at 9:27 PM, Iavor Diatchki wrote:

Hello,

this is clearly a bug in GHC: where `B` and `C` are imported, there should have been an error, saying that there is a duplicate instance of `Foo Int`. If there is no ticket for this already, could you please add one?

-Iavor

On Mon, Aug 11, 2014 at 12:35 PM, Dan Doel wrote: On Mon, Aug 11, 2014 at 11:36 AM, Twan van Laarhoven wrote: To me, perhaps naively, IncoherentInstances is way more scary than OverlappingInstances.

​It might be a bit naive. Most things that incoherent instances would allow are allowed with overlapping instances so long as you partition your code into two modules. So unless such a partitioning is impossible, overlapping instances are almost as scary as incoherent instances (unless the module separation somehow makes it less scary).

And actually, with the way GHC handles instances, you can get more incoherent behavior than incoherent instances allow without enabling any extensions, just using modules:

module A where class Foo a where foo :: a

module B where import A instance F​​oo Int where foo = 5 bar :: Int ; bar = foo

module C where import A instance Foo Int where foo = 6 baz :: Int ; baz = foo

module D where import B import C

quux = bar + baz -- 11​​

-- ​ Dan​

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users