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

[Richard Eisenberg]

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