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

Hello, I'd be surprised if there is a lot of code affected by that. Either way, I guess this wouldn't be an issue, if we just changed the proposal to make the default instance for `typedLift` looks like the old default for `lift` (i.e., use the `Data` constraint). The proposed design does have two benefits though: * The new design requires fewer GHC extensions (no need for `DefaultSignatures`) * It encourages programmers to use `DeriveLift`, which is shorter, safer, and more direct. -Iavor On Mon, Nov 5, 2018 at 10:50 AM 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?

(Yes, yes, I know that I could voiced this opinion earlier, but it didn't occur to me until just now.)

Richard

...

On Nov 5, 2018, at 1:37 PM, Ben Gamari wrote:

Hi everyone,

I have been asked to Shepard #175, which proposes to add a `liftTyped` method to the `Lift` typeclass used to lift Haskell values into Template Haskell splices. Currently the `Lift` typeclass provides no guarantee of type-safety, even when used in a Typed Template Haskell context.

The proposal resolves this limitation by adding a typed lifting operation to the `Lift` class:

class Lift t where lift :: t -> Q Exp liftTyped :: t -> Q (TExp t)

While this addition will break manually-written `Lift` instances, we recommended that users derive such instances for quite a while now, so it is not expected that the breakage will be wide-spread. In light of this, I recommend that we accept this proposal.

Given that we will likely want to get this in to 8.8, I suggest that we limit the discussion to a week unless there is dissent.

Cheers,

- Ben _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee