Overlapping and incoherent instances
Twan van Laarhoven
twanvl at gmail.com
Mon Aug 11 15:36:51 UTC 2014
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 at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
More information about the Glasgow-haskell-users
mailing list