The proposed change to my library is here: https://github.com/tibbe/cassava/pull/95/files

We remove the OverlappingInstances pragma and instead add an OVERLAPPABLE pragma like so:

instance {-# OVERLAPPABLE #-} FromField a => FromField (Maybe a) where

This causes clients of the library that previously compiled (e.g. the music-parts package) to no longer compile, due to a now lacking OVERLAPPING pragma in their code.

The issue here is I'm trying to the right thing (move to new pragmas), but that causes clients to fail to compile. My question is: how do we avoid that? Would it be OK if they added the OVERLAPPING pragma first and then I change my library to use OVERLAPPABLE?

On Tue, Aug 25, 2015 at 1:25 PM, Simon Peyton Jones <simonpj@microsoft.com> wrote:

What's the right way to migrate code? Just switching my library to the new pragmas breaks code, so that doesn't seem very attractive.

I don’t understand. Can you describe the problem more precisely, perhaps with an example?

S

From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Johan Tibell
Sent: 25 August 2015 10:42
To: ghc-devs@haskell.org
Subject: OVERLAPPABLE/OVERLAPPING/OVERLAPS pragmas are confusing

It was brought to my attention that cassava, my library, uses OverlappingInstances, which is now deprecated. There's a suggested fix here: https://github.com/tibbe/cassava/pull/95.

The fix seems correct but, as Mikhail points out, makes some client code no longer compile (due to a now missing OVERLAPPABLE pragma).

What's the right way to migrate code? Just switching my library to the new pragmas breaks code, so that doesn't seem very attractive. Do clients have to migrate before the libraries they use?

-- Johan