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

[Eric Seidel]

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).