- Glasgow-haskell-users

Re: Overlapping and incoherent and intentionally omitted instances
by Iavor Diatchki 10 Aug '14

10 Aug '14

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 < schlepptop(a)henning-thielemann.de> 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? > >

1 0

cabal repl failing silently on missing exposed-modules
by cheater00 . 08 Aug '14

08 Aug '14

Hi, I have just spent some time trying to figure out why all of a sudden "cabal repl" silently exits without an error message. What helped was to take a project that could launch the repl and compare the cabal files to my new project. It turns out the exposed-modules entry was missing. I was wondering whether this behaviour was intentional, as I don't recollect this happening before, but I don't have older systems to test this on. The reason I wanted to run a repl without editing exposed modules was to test some dependencies I pulled in to the sandbox with cabal install. The package in question didn't have any code of its own yet. In this case I would just expect ghci to load with the Prelude. Thanks!

3 5

Re: Overlapping and incoherent instances
by Ben Millwood 07 Aug '14

07 Aug '14

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 >>Libraries(a)haskell.org >>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 :(

4 4

Old code broken by new Typeable class
by Volker Wysk 05 Aug '14

05 Aug '14

Hi! I've been working with GHC-4.6.3, and updating to GHC-4.8.3 breaks my code, because the Typeable class has been changed. The compiler produces this message: --------- src/HsShellScript/ProcErr.chs:2294:4: ‘typeOf’ is not a (visible) method of class ‘Typeable’ --------- I want to define System.Posix.Process.ProcessStatus to be an instance of Typeable, so I can throw and catch it as an exception. ProcessStatus isn't typeable by default. Is it still possible to make ProcessStatus a member of Typeable? How? Obviously, you can't accomplish it by deriving Typeable, because the definition can't be changed any longer. This is the spot in question: ---------- import System.Posix.Process import Data.Typeable {- data ProcessStatus = Exited ExitCode / | Terminated Signal/ / | Stopped Signal/ deriving (Eq, Ord, Show) -} instance Typeable ProcessStatus where typeOf = const tyCon_ProcessStatus tyCon_ProcessStatus = mkTyConApp (mkTyCon3 "hsshellscript" "HsShellScript.ProcErr" "Posix.ProcessStatus") [] instance Exception ProcessStatus ---------- Thanks, V.W.

5 9

Cross compiling for Cortex A9
by Michael Jones 05 Aug '14

05 Aug '14

I am having problems building a GHC cross compiler for Linux (Yocto on a Wandboard) running on a Cortex A9, and need some advice on how to debug it. The cross compiler produces an executable that runs on the Target, but fails to print. So I need help coming up with a strategy to narrow down the root cause. Some details: The application: main = do putStrLn "Haskell start" The command line options work. The program runs, and I can step through assembly. Debug data is printed to the console. But putStrLn fails, and program enters an infinite loop. I compile my app as follows: arm-unknown-linux-gnueabi-ghc -debug -static Main.hs Using -threaded does not fix the problem. Let me compare debug data from a run on my HOST, with a run on my TARGET. First, a run from my HOST: created capset 0 of type 2 created capset 1 of type 3 cap 0: initialised assigned cap 0 to capset 0 assigned cap 0 to capset 1 cap 0: created thread 1 cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (suspended while making a foreign call) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (finished) cap 0: created thread 2 cap 0: running thread 2 (ThreadRunGHC) cap 0: thread 2 stopped (finished) cap 0: starting GC cap 0: GC working cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: all caps stopped for GC cap 0: finished GC removed cap 0 from capset 0 removed cap 0 from capset 1 cap 0: shutting down deleted capset 0 deleted capset 1 And, it prints properly. So this is my referenced for what it should do on the TARGET. When I run on my TARGET, I get: created capset 0 of type 2 created capset 1 of type 3 cap 0: initialised assigned cap 0 to capset 0 assigned cap 0 to capset 1 cap 0: created thread 1 cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (heap overflow) cap 0: starting GC cap 0: GC working cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: all caps stopped for GC cap 0: finished GC cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) ... And the debug data goes on forever, just as debugging assembly demonstrated an infinite loop. Clearly, the following does not occur: cap 0: thread 1 stopped (suspended while making a foreign call) And there are overflows. If I had to guess, it is possible that some code is in a loop retrying to foreign call, and failing. Certainly, it is in some kind of a loop, because I found a place I can put a break point and and telling GDB to continue will cause the break over and over at the same place. So somewhere there is a loop. I can step through the application with GDB and see names of files and offsets in assembly. But without a true source code debug, that is a bit rough, especially for someone that does not know the RTS code. If there was a way to compile such that C source code was available and a place to break, that would help. However, I suspect since it never makes a foreign call, there is no place in C to place the breakpoint anyway. So I am also assuming there is no direct way to debug with GDB. But, I can see debug output printed to the console. My hope is there is a way to enable more printing, or a place I can add more print functions to help find the problem. So I think I need one of the following: - A solution from someone that has seen this before, perhaps on the iPhone - How to enable more debug logging - Where in the source code to add debug statements to narrow down the problem Thanks for any help you can give. Mike

4 22

RE: Overlapping and incoherent instances
by Simon Peyton Jones 31 Jul '14

31 Jul '14

| 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(a)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(a)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(a)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(a)gu.se | > | http://www2.tcs.ifi.lmu.de/~abel/ | > | _______________________________________________ | > | Libraries mailing list | > | Libraries(a)haskell.org | > | http://www.haskell.org/mailman/listinfo/libraries | > _______________________________________________ | > Libraries mailing list | > Libraries(a)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(a)gu.se | http://www2.tcs.ifi.lmu.de/~abel/

1 0

RE: Overlapping and incoherent instances
by Simon Peyton Jones 31 Jul '14

31 Jul '14

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(a)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(a)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(a)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(a)gu.se | http://www2.tcs.ifi.lmu.de/~abel/ | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

2 1

Re: Overlapping and incoherent instances
by Johan Tibell 30 Jul '14

30 Jul '14

On Wed, Jul 30, 2014 at 2:50 PM, Ivan Lazar Miljenovic <ivan.miljenovic(a)gmail.com> wrote: > On 30 July 2014 22:07, Andreas Abel <andreas.abel(a)ifi.lmu.de> 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?

1 0

Re: Overlapping and incoherent instances
by Iavor Diatchki 29 Jul '14

29 Jul '14

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 <davidleothomas(a)gmail.com> wrote: > Honestly, I think "OVERLAPS" and "OVERLAPPED" are perfectly clear. > > On Tue, Jul 29, 2014 at 9:52 AM, David Feuer <david.feuer(a)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 > > <simonpj(a)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] 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(a)haskell.org) ghc-devs > >> > >> > >> Subject: Re: Overlapping and incoherent instances > >> > >> > >> > >> How about CAN_OVERLAP? > >> > >> -- > >> Krzysztof > >> > >> 29-07-2014 15:40, "Brandon Allbery" <allbery.b(a)gmail.com> napisał(a): > >> > >> On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel <andreas.abel(a)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(a)gmail.com > ballbery(a)sinenomine.net > >> > >> unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > >> > >> > >> _______________________________________________ > >> Libraries mailing list > >> Libraries(a)haskell.org > >> http://www.haskell.org/mailman/listinfo/libraries > >> > >> > >> _______________________________________________ > >> Libraries mailing list > >> Libraries(a)haskell.org > >> http://www.haskell.org/mailman/listinfo/libraries > >> > > _______________________________________________ > > Libraries mailing list > > Libraries(a)haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries >

1 0

Re: Overlapping and incoherent instances
by Herbert Valerio Riedel 29 Jul '14

29 Jul '14

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.

6 7