[ghc-steering-committee] Proposal #209: Levity polymorphic lift. Recommendation: accept

[Eric Seidel]

That's true, thank you for reminding me of our previous discussion about this issue.

I recall suggesting earlier a one-off error for empty Lift instances. It's kludgy, but easy to implement and deploy since TH is bundled with GHC. And it makes the problem go away entirely. This solution seems more compelling than it did before, since we now have a good reason for wanting both methods in the class.

Eric

On Mon, Mar 4, 2019, at 22:30, Richard Eisenberg wrote:
> Thanks, Eric.
> 
> So, if we restore lift (and have it be defined in terms of liftTyped) 
> to the Lift class, then we potentially have a problem. This is allowed 
> today (and it works well):
> 
> > data Foo
> >   deriving Data
> > instance Lift Foo
> 
> But after this proposal, it will still be accepted **but will loop**. 
> That is, the instance silently becomes a bomb waiting to maim poor 
> clients with an obscure compile-time hang. Because of the MINIMAL 
> pragma, there will be a warning. So perhaps we decide that the warning 
> is enough of a deterrent and to allow this strange back-compat story.
> 
> On the other hand, if we remove lift from the class, then the above 
> code fails with a "liftTyped is not defined" error. That's quite easy 
> to pinpoint.
> 
> I'm not wholly against this proposal at all -- indeed, it's a nice 
> application of levity polymorphism -- but I think there is a real 
> drawback here worth debating.
> 
> Richard
> 
> > On Mar 4, 2019, at 10:19 PM, Eric Seidel <eric at seidel.io> wrote:
> > 
> > I believe you're thinking of https://github.com/ghc-proposals/ghc-proposals/pull/175. The PR has been marked accepted, but it seems it didn't get merged.
> > 
> > On Mon, Mar 4, 2019, at 22:16, Richard Eisenberg wrote:
> >> I recall a discussion in another proposal about the Lift class and 
> >> removing the lift function. This was for a good reason (I think it 
> >> stopped silent, terrible breakage). Does anyone remember where that 
> >> conversation took place? A quick search didn't find an accepted 
> >> proposal about the Lift class.
> >> 
> >> Thanks,
> >> Richard
> >> 
> >>> On Mar 2, 2019, at 4:41 PM, Eric Seidel <eric at seidel.io> wrote:
> >>> 
> >>> Hi everyone,
> >>> 
> >>> This proposal[1] makes the `lift` and `liftTyped` methods of the `Lift` class levity-polymorphic, which allows us to write proper `Lift` instances for unlifted types. It would also allow GHC to remove the special logic that currently supports lifting records with unlifted fields.
> >>> 
> >>> The main downside is the potential for breakage since `lift @Foo` would now fix the RuntimeRep parameter rather than the `a`. This is unfortunate, but I doubt it will show up much. It also unfortunately requires making both `lift` and `liftTyped` methods, when we had just decided to extract `lift` from the class. 
> >>> 
> >>> I recommend accepting the proposal.
> >>> 
> >>> Thanks!
> >>> Eric
> >>> 
> >>> [1]: https://github.com/harpocrates/ghc-proposals/blob/levity-polymorphic-lift/proposals/0000-levity-polymorphic-lift.rst
> >>> _______________________________________________
> >>> ghc-steering-committee mailing list
> >>> ghc-steering-committee at haskell.org
> >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >> 
> >> 
> 
>