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

[Iavor Diatchki]

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 <rae at cs.brynmawr.edu>
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 <ben at well-typed.com> 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 at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20181105/44c057c5/attachment-0001.html>