[ghc-steering-committee] [Proposal] #175: Lift.liftTyped (recommendation: accept)

[Eric Seidel]

Though on second thought, this still doesn’t exactly provide a clean migration path.

If I depend on version X of some library that uses the default implementation of lift, and I upgrade to a new GHC with the new Lift class, version X of my dependency will continue to compile, albeit with a warning. But I probably don’t pay much attention to warnings in my dependencies (and almost certainly don’t compile them with -Werror), so I may still be caught off-guard by the change. 

Sent from my iPhone

> On Nov 5, 2018, at 12:51, Eric Seidel <eric at seidel.io> wrote:
> 
>> On Mon, Nov 5, 2018, at 13:50, Richard Eisenberg wrote:
>> Will this break existing code? The proposal suggests that liftTyped will 
>> have a suitable default implementation.
>> 
>> Actually, this will break code, but not in the way one might think (with 
>> an undefined liftTyped). Instead, the proposal removes the default 
>> implementation of lift to use liftTyped. This means that any code 
>> relying on the default implementation of lift will now have an instance 
>> with mutually recursive, non-terminating methods. And this will all be 
>> silent. And, it's something that might be discovered only in clients of 
>> a library, rather than in the library itself. So I think that's pretty 
>> problematic. Even with our recommendation to derive Lift instances, this 
>> change in behavior is so terrible that it makes me lean against the 
>> proposal. Is there a design / migration path that avoids this problem?
> 
> The current iteration of the proposal has a MINIMAL pragma on Lift, specifying that either lift or liftTyped must be explicitly implemented.
> 
>  https://github.com/harpocrates/ghc-proposals/blob/lift-typed/proposals/0000-lift-typed.rst#2proposed-change-specification
> 
> So code that currently relies on the default implementation of lift will indeed break, but not silently! The library author will get a warning that they need to provide lift or liftTyped (or, preferably, switch to DeriveLift).