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

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

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