Re: Overlapping and incoherent instances
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@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 :(
| >>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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
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.
This would be a reasonable alternative to the keyword-based solution. At least for now. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJT45F5AAoJENEcKRHOUZzewwwQALUiK60sbIC6j5nbXHPCeau8 bN80pmhUL11lAyI7OCSQyV8S9AU7ikgaUPyKwk/cx/TtKQGLwghWFZlRCoCRrplk dmGsSCw2LN4GElHL22EcyELPcx74lknz3tmQuZg4oAUXm1h2w8774L3iHOE4Ompg 9gYzuOo8Ii3oHJ6fjIL0DwGWp92F8NrTPeQmziBOPHAgQYVFO8QMncXcOGtdIZUb PQr0szr9HLkcwKSrYoxvvZBqEj6AM0xj+KhX87NEnQ08EaY6FO/Dhm4mi7X/A5Ca khwsjwId0qR6C4vs7QyYnaK3yiUFlZMUlXdUhpRG3wWFHseb3m9tX2a2ewE30jPl TgnoU5NYphijMWXpc3p06D5Zj0lT6L++Y3Ez8CS+0QpBPG9c0CJnLqXFQ5CNbl+9 Ryzpg7ltg5vhtq7BLwcz+V87lzc4KYm/tyqEVvxN59W6XLuLLe4tW6NL9vLDl9Rg /3vMRYKZBa+0we7jAi/wYbdks7g+9sqpiLqke5m73a5F2j/TTl4BrkIj2vG0KrP+ G9eJC1aieUbfPXXwXWSJh8binJNp//qWs7rILDsx4r0o1QR245uT5WzwkwapXmE8 ZYuXsVcc1/mS1ZneOP6zn0QOlRcUJ0A5dFxQg69hsXpD+MM226r/57P3eI9XhLRN W+DNBoXbr9mp8eNGjl6O =CFkA -----END PGP SIGNATURE-----
Simon Peyton Jones wrote:
| >>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
I'm curious how this affects simplification of contexts. If I have class Foo a instance Foo a => Foo [a] then GHC will simplify foo :: Foo [a] => a -> () to foo :: Foo a => a -> () Would this be prevented by declaring the Foo [a] instance as overlappable? In other words, does OVERLAPPABLE instruct the type checker to expect overlapping instances even if none of them are visible? Cheers, Bertram
| overlappable? In other words, does OVERLAPPABLE instruct the | type checker to expect overlapping instances even if none of | them are visible? No, not at the moment. Suppose we have class C a where op :: a -> String instance {-# OVERLAPPABLE #-} C a => C [a] where op x = "[a]" instance {-# OVERLAPPING #-} C [Int] where op x = "[Int]" foo :: C a => a -> String foo x = op [x] ++ "urk" Then we (rightly) get an overlapping instance error when we try to solve the (C [a]) constraint arising from op [a] in foo's RHS. But if we omit the type signature for foo, then GHC will (as before) not simplify the (C [a]) constraint, for the same reason, but because it's unsolved GHC will abstract over it to give the inferred type foo :: C [a] => a -> String But this only happens if the overlapping instance is visible here. If the C [Int] instance is in some other module, then GHC will infer foo :: C a => a -> String. Your point is that if the C [a] instance is marked OVERLAPPABLE, perhaps GHC should decline to simplify it, on the grounds that a more specific instance might appear. But then the (C [a]) instance would never, ever be used! (On the grounds that it might be overlapped by some as-yet-unseen instance. So I don't think this would work. In any case, if the current behaviour doesn't seem precisely defined by the user manual, could you suggest some words that would make it clearer? Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Bertram Felgenhauer | Sent: 07 August 2014 16:25 | To: glasgow-haskell-users@haskell.org | Subject: Re: Overlapping and incoherent instances | | Simon Peyton Jones wrote: | > | >>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 | | I'm curious how this affects simplification of contexts. If I have | | class Foo a | instance Foo a => Foo [a] | | then GHC will simplify | | foo :: Foo [a] => a -> () | | to | | foo :: Foo a => a -> () | | Would this be prevented by declaring the Foo [a] instance as | overlappable? In other words, does OVERLAPPABLE instruct the | type checker to expect overlapping instances even if none of | them are visible? | | Cheers, | | Bertram | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
participants (4)
-
Ben Millwood -
Bertram Felgenhauer -
Simon Peyton Jones -
Stephen Paul Weber