Re: Overlapping and incoherent instances
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
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
On Mon, Aug 11, 2014 at 11:36 AM, Twan van Laarhoven twa...@gmail.com 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
Hello, this is clearly a bug in GHC: where `B` and `C` are imported, there should have been an error, saying that there is a duplicate instance of `Foo Int`. If there is no ticket for this already, could you please add one? -Iavor On Mon, Aug 11, 2014 at 12:35 PM, Dan Doel dan.d...@gmail.com wrote: On Mon, Aug 11, 2014 at 11:36 AM, Twan van Laarhoven twa...@gmail.com 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 librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
This has been reported: https://ghc.haskell.org/trac/ghc/ticket/8338 But it's really not clear what the solution is! Richard On Aug 11, 2014, at 9:27 PM, Iavor Diatchki iavor.diatc...@gmail.com wrote: Hello, this is clearly a bug in GHC: where `B` and `C` are imported, there should have been an error, saying that there is a duplicate instance of `Foo Int`. If there is no ticket for this already, could you please add one? -Iavor On Mon, Aug 11, 2014 at 12:35 PM, Dan Doel dan.d...@gmail.com wrote: On Mon, Aug 11, 2014 at 11:36 AM, Twan van Laarhoven twa...@gmail.com 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 Foo 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 librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
