Overlapping and incoherent instances

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Johan Tibell-2
On Wed, Jul 30, 2014 at 2:50 PM, Ivan Lazar Miljenovic
<[hidden email]> wrote:

> On 30 July 2014 22:07, Andreas Abel <[hidden email]> 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?
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Andreas Abel
@Johan: imho, your question does make sense.

Say I am issueing a library with

   instance Bla Char
   instance Bla a => Bla [a]

   instance Blubb Char
   instance Blubb String

then, by the proposed distinction, the user of my library would have to
write

   instance {-# OVERLAPPING #-} Bla String

but

   instance {-# OVERLAPPABLE #-} Blubb a => Blubb [a]

I would not know why the user has to be burdened with such quibbles.  A
simple

   instance {-# OVERLAP #-} Bla String
   instance {-# OVERLAP #-} Blubb a => Blubb [a]

to shut off the compiler complaining about non-unique solutions
involving these *additional* instance would do the job.

The semantics would be:  Whenever an instance adds *new* ambiguities, it
has to be marked with OVERLAP.

And, there should be monotonicity such that the user can mark any
instance as OVERLAP even though there is no actual overlap (otherwise
things become mad when switching import ordering etc.).


On 30.07.2014 14:55, Johan Tibell wrote:

> On Wed, Jul 30, 2014 at 2:50 PM, Ivan Lazar Miljenovic
> <[hidden email]> wrote:
>> On 30 July 2014 22:07, Andreas Abel <[hidden email]> 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 Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

AntC
In reply to this post by Niklas Haas
> Simon Peyton Jones
> Tue Jul 29 09:11:05 UTC 2014
> ...
> This is a Big Hammer.

I agree with Simon's motivation that the whole-module overlap pragma is
often too brutal.

But I think that what Iavor has developed is still too brutal.
(Sorry, and I hadn't known about these instance-level pragmas before now.)

For my 2d, I think Andreas made an important distinction:

> Andreas Abel andreas.abel at ifi.lmu.de
> Wed Jul 30 12:07:01 UTC 2014
>  The German equivalent of "overlap", ..., 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'd say that the English "overlap" is also used in a symmetrical fashion
(outside of specialist Haskell instances usage).

There's a difference between:
- this instance is nec. narrower than some other instance
  (IOW anything that's a substitution for this instance,
   is ipso facto a substitution for some wider)
- vs. a partial overlap
  (some substitutions will fit this instance only,
   some will fit another instance, not this one,
   some will fit both)

In my experience, unintended partial overlaps are the nastiest to diagnose.
And partial overlaps are very seldom needed in practice.
They're often a symptom that two separately-developed libraries are
clashing.

(For example the HList libraries -- as originally released --
 used overlap extensively, but no partial overlaps.)

So I would like the pragmas to be able to say:
this instance subsumes or is subsumed by some other instance
but it must not partially overlap any instance.

(I guess this is beyond the question Simon's OP asked.)


AntC

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Overlapping and incoherent instances

Simon Peyton Jones
In reply to this post by Simon Peyton Jones

Friends, in sending my message below, I should also have sent a link to

            https://ghc.haskell.org/trac/ghc/ticket/9242#comment:25

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:[hidden email]] On Behalf Of Simon Peyton Jones
Sent: 29 July 2014 10:11
To: ghc-devs; GHC users; Haskell Libraries ([hidden email])
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.

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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Andreas Abel-2
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:[hidden email]] *On Behalf Of
> *Simon Peyton Jones
> *Sent:* 29 July 2014 10:11
> *To:* ghc-devs; GHC users; Haskell Libraries ([hidden email])
> *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
> [hidden email]
> 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

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Overlapping and incoherent instances

Simon Peyton Jones
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:[hidden email]] On Behalf Of
| Andreas Abel
| Sent: 31 July 2014 08:59
| To: Simon Peyton Jones; ghc-devs; GHC users; Haskell Libraries
| ([hidden email])
| 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:[hidden email]] *On Behalf Of
| > *Simon Peyton Jones
| > *Sent:* 29 July 2014 10:11
| > *To:* ghc-devs; GHC users; Haskell Libraries ([hidden email])
| > *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
| > [hidden email]
| > 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
|
| [hidden email]
| http://www2.tcs.ifi.lmu.de/~abel/
| _______________________________________________
| Libraries mailing list
| [hidden email]
| http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Edward Kmett-2
Now if only we could somehow find a way to do the same thing for AllowAmbiguousTypes. :)

I have a 2500 line file that I'm forced to turn on AllowAmbiguousTypes in for 3 definitions, and checking that I didn't accidentally make something else ambiguous to GHC's eyes is a rather brutal affair. (I can't break up the file without inducing orphans)

This is just a passing comment, while I'm thinking about it, not a serious attempt to derail the topic!

-Edward


On Thu, Jul 31, 2014 at 4:13 AM, Simon Peyton Jones <[hidden email]> 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:[hidden email]] On Behalf Of
| Andreas Abel
| Sent: 31 July 2014 08:59
| To: Simon Peyton Jones; ghc-devs; GHC users; Haskell Libraries
| ([hidden email])
| Subject: Re: Overlapping and incoherent instances
|
| On <a href="tel:31.07.2014%2009" value="+13107201409">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:[hidden email]] *On Behalf Of
| > *Simon Peyton Jones
| > *Sent:* 29 July 2014 10:11
| > *To:* ghc-devs; GHC users; Haskell Libraries ([hidden email])
| > *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
| > [hidden email]
| > 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
|
| [hidden email]
| http://www2.tcs.ifi.lmu.de/~abel/
| _______________________________________________
| Libraries mailing list
| [hidden email]
| http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Andreas Abel-2
In reply to this post by Simon Peyton Jones
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:[hidden email]] On Behalf Of
> | Andreas Abel
> | Sent: 31 July 2014 08:59
> | To: Simon Peyton Jones; ghc-devs; GHC users; Haskell Libraries
> | ([hidden email])
> | 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:[hidden email]] *On Behalf Of
> | > *Simon Peyton Jones
> | > *Sent:* 29 July 2014 10:11
> | > *To:* ghc-devs; GHC users; Haskell Libraries ([hidden email])
> | > *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
> | > [hidden email]
> | > 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
> |
> | [hidden email]
> | http://www2.tcs.ifi.lmu.de/~abel/
> | _______________________________________________
> | Libraries mailing list
> | [hidden email]
> | http://www.haskell.org/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> [hidden email]
> 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

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Overlapping and incoherent instances

Simon Peyton Jones
| 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:[hidden email]] On Behalf Of
| > | Andreas Abel
| > | Sent: 31 July 2014 08:59
| > | To: Simon Peyton Jones; ghc-devs; GHC users; Haskell Libraries
| > | ([hidden email])
| > | 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:[hidden email]] *On
| Behalf
| > | > Of *Simon Peyton Jones
| > | > *Sent:* 29 July 2014 10:11
| > | > *To:* ghc-devs; GHC users; Haskell Libraries
| > | > ([hidden email])
| > | > *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
| > | > [hidden email]
| > | > 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
| > |
| > | [hidden email]
| > | http://www2.tcs.ifi.lmu.de/~abel/
| > | _______________________________________________
| > | Libraries mailing list
| > | [hidden email]
| > | http://www.haskell.org/mailman/listinfo/libraries
| > _______________________________________________
| > Libraries mailing list
| > [hidden email]
| > 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
|
| [hidden email]
| http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Andreas 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:[hidden email]] On Behalf Of
> | > | Andreas Abel
> | > | Sent: 31 July 2014 08:59
> | > | To: Simon Peyton Jones; ghc-devs; GHC users; Haskell Libraries
> | > | ([hidden email])
> | > | 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:[hidden email]] *On
> | Behalf
> | > | > Of *Simon Peyton Jones
> | > | > *Sent:* 29 July 2014 10:11
> | > | > *To:* ghc-devs; GHC users; Haskell Libraries
> | > | > ([hidden email])
> | > | > *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
> | > | > [hidden email]
> | > | > 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
> | > |
> | > | [hidden email]
> | > | http://www2.tcs.ifi.lmu.de/~abel/
> | > | _______________________________________________
> | > | Libraries mailing list
> | > | [hidden email]
> | > | http://www.haskell.org/mailman/listinfo/libraries
> | > _______________________________________________
> | > Libraries mailing list
> | > [hidden email]
> | > 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
> |
> | [hidden email]
> | http://www2.tcs.ifi.lmu.de/~abel/
> _______________________________________________
> Libraries mailing list
> [hidden email]
> 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

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Ben Millwood
In reply to this post by Simon Peyton Jones
On Thu, Jul 31, 2014 at 07:20:31AM +0000, Simon Peyton Jones wrote:
>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").

Here's one concern I have with the deprecation of
-XOverlappingInstances: I don't like overlapping instances, I find them
confusing and weird and prefer to use code that doesn't include them,
because they violate my expectations about how type classes work. When
there is a single LANGUAGE pragma, that's a simple, easily-checkable
signpost of "this code uses techniques that Ben doesn't understand".
When it is all controlled by pragmas I basically have to check every
instance declaration individually.

On a largely unrelated note, here's another thing I don't understand:
when is OVERLAPPABLE at one instance declaration preferable to using
only OVERLAPPING at the instance declarations that overlap it? In the
latter model, as long as none of the instances I write have pragmas, I
can be sure none of them overlap. In the former model, any instance I
write for an existing typeclass might overlap another instance, even if
I don't want it to. Do we have any specific use cases in mind for
OVERLAPPABLE?
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Ben Millwood
On Sat, Aug 02, 2014 at 08:51:57PM +0100, Ben Millwood wrote:

>On Sat, Aug 02, 2014 at 04:27:14PM +0100, Ben Millwood wrote:
>>On Thu, Jul 31, 2014 at 07:20:31AM +0000, Simon Peyton Jones wrote:
>>>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").
>>
>>Here's one concern I have with the deprecation of
>>-XOverlappingInstances: I don't like overlapping instances, I find
>>them confusing and weird and prefer to use code that doesn't
>>include them, because they violate my expectations about how type
>>classes work. When there is a single LANGUAGE pragma, that's a
>>simple, easily-checkable signpost of "this code uses techniques
>>that Ben doesn't understand". When it is all controlled by pragmas
>>I basically have to check every instance declaration individually.
>>
>>On a largely unrelated note, here's another thing I don't
>>understand: when is OVERLAPPABLE at one instance declaration
>>preferable to using only OVERLAPPING at the instance declarations
>>that overlap it? In the latter model, as long as none of the
>>instances I write have pragmas, I can be sure none of them overlap.
>>In the former model, any instance I write for an existing typeclass
>>might overlap another instance, even if I don't want it to. Do we
>>have any specific use cases in mind for OVERLAPPABLE?
>>_______________________________________________
>>Libraries mailing list
>>[hidden email]
>>http://www.haskell.org/mailman/listinfo/libraries
>
>When I originally sent this mail I wasn't subscribed to the GHC
>lists, so I went and fixed that and am now resending.

Good grief, and then I sent from the wrong address. Sorry for the noise.

>Addendum: I was surprised by the behaviour of overlapping instances
>when I went and looked closer at it.
>
>    {-# LANGUAGE FlexibleInstances #-}
>    module M where
>    class C a where f :: a -> a
>    instance C a where f x = x
>    instance C Int where f x = x + 1
>
>I suspect many people have the intuition that NoOverlappingInstances
>should forbid the above, but in fact OverlappingInstances or no only
>controls instance *resolution*. I imagine you all already knew this
>but I did not until I carefully reread things.
>
>As someone who dislikes overlapping type class instances, I am
>finding them harder to avoid than I at first thought :(
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Overlapping and incoherent instances

Simon Peyton Jones
| >>Here's one concern I have with the deprecation of
| >>-XOverlappingInstances: I don't like overlapping instances, I find
| >>them confusing and weird and prefer to use code that doesn't
| >>include them, because they violate my expectations about how type
| >>classes work. When there is a single LANGUAGE pragma, that's a
| >>simple, easily-checkable signpost of "this code uses techniques
| >>that Ben doesn't understand". When it is all controlled by pragmas
| >>I basically have to check every instance declaration individually.

I see your point.  Though you could just grep for OVERLAP!

I suppose that -XOverlappingInstances could mean "silently honour OVERLAPPABLE/OVERLAPPING pragmas", while lacking it would mean "honour OVERLAPPABLE/OVERLAPPING pragmas, but emit noisy warnings" or even "don't honour them and warn".

But that is different to the behaviour today, so we'd need a new LANGUAGE pragma.  Perhaps -XHonourOverlappingInstances or something.

My sense is that the extra faff is not worth it.

| >>On a largely unrelated note, here's another thing I don't
| >>understand: when is OVERLAPPABLE at one instance declaration
| >>preferable to using only OVERLAPPING at the instance declarations
| >>that overlap it?

It's a user decision.  GHC allows
  - OVERLAPPABLE at the instance that is being overlapped, or
  - OVERLAPPING at the instance that is doing the overlapping, or
  - both

Another possible choice would be to require both.  One or t'other wouldn't do.  But the current choice (with the LANGUAGE pragmas -XOverlappingInstances) is the either/or choice, and I had no user pressure to change that.  There *is* user pressure for the either/or semantics, so that you can *later* add an un-anticipated OVERLAPPING instance.

| >    {-# LANGUAGE FlexibleInstances #-}
| >    module M where
| >    class C a where f :: a -> a
| >    instance C a where f x = x
| >    instance C Int where f x = x + 1
| >
| >I suspect many people have the intuition that NoOverlappingInstances
| >should forbid the above, but in fact OverlappingInstances or no only
| >controls instance *resolution*. I imagine you all already knew this
| >but I did not until I carefully reread things.

It's pretty clearly stated in the manual, but I'd be delighted to add a paragraph or two, or an example, if you can draft something and say where a good place for it would be (ie where you'd have looked).

Thanks

Simon

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Suppress warning on certain unknown pragmas (Was: Overlapping and incoherent instances)

Henning Thielemann-4
In reply to this post by Richard Eisenberg-2
Am 29.07.2014 um 14:13 schrieb Richard Eisenberg:

> I think one nice thing about this proposal is that it doesn't seem (to me) to require CPP around the pragma: unrecognized pragmas are warned about but are otherwise harmless. Are folks very keen to have *warning-free* compilation on several GHC versions?

I'd prefer to tell GHC, to not warn about a given list of pragmas. E.g.
I would have liked to tell GHC-7.4 about the new MINIMAL pragma that I
added to some of my libraries. There might also be pragmas used for
other tools or compilers that GHC should ignore.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent and intentionally omitted instances

Henning Thielemann-4
In reply to this post by Johan Tibell-2
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?

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Henning Thielemann-4
In reply to this post by Simon Peyton Jones
Am 29.07.2014 um 11:11 schrieb Simon Peyton Jones:

> 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.

I think it is a good opportunity to check whether overlapping instances
are really needed. There might be cases where instances actually do not
overlap (anymore), like you encountered, and cases where a little
redesign avoids overlapping. As far as I remember I could eventually
avoid any overlapping instance in my packages.

That said, I prefer to write the pragma before the instances, like
INLINE pragmas.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent and intentionally omitted instances

Iavor Diatchki
In reply to this post by Henning Thielemann-4
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.

-Iavor


On Sun, Aug 10, 2014 at 7:19 AM, Henning Thielemann <[hidden email]> wrote:
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?



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent and intentionally omitted instances

Henning Thielemann-4
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

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Twan van Laarhoven
In reply to this post by Simon Peyton Jones
To me, perhaps naively, IncoherentInstances is way more scary than
OverlappingInstances.

What behavior do these new pragmas have? In particular, will it be an error if
there is no single most specific instance? And can the user decide whether it is
an error?

Twan

On 29/07/14 11:11, Simon Peyton Jones wrote:

> 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
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Overlapping and incoherent instances

Dan Doel
On Mon, Aug 11, 2014 at 11:36 AM, Twan van Laarhoven <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
123