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

Tue Mar 5 13:40:34 UTC 2019

... and keeping lift in the type class is necessary now because moving it outside the class would violate levity-polymorphic binder restrictions.

Richard

> On Mar 5, 2019, at 6:59 AM, Eric Seidel <eric at seidel.io> wrote:
> 
> It’s not that lift has become levity-polymorphic, rather both lift and liftTyped are back in Lift with mutually recursive default implementations. 
> 
> Sent from my iPhone
> 
>> On Mar 5, 2019, at 03:13, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>> 
>> | > 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.
>> 
>> Can you remind us why making Lift levit-polymorphic causes this change in looping behaviour?
>> 
>> Simon
>> 
>> | -----Original Message-----
>> | From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
>> | On Behalf Of Richard Eisenberg
>> | Sent: 05 March 2019 03:30
>> | To: Eric Seidel <eric at seidel.io>
>> | Cc: ghc-steering-committee at haskell.org
>> | Subject: Re: [ghc-steering-committee] Proposal #209: Levity polymorphic
>> | lift. Recommendation: accept
>> | 
>> | 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
>> | m%2Fghc-proposals%2Fghc-
>> | proposals%2Fpull%2F175&data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89
>> | 805fa4e1a3f6008d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6368
>> | 73534124463833&sdata=WUd8z511ysFVYxvhdpYCtw0useZOtOq37VANULn%2BHd8%3D&a
>> | mp;reserved=0. 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
>> | m%2Fharpocrates%2Fghc-proposals%2Fblob%2Flevity-polymorphic-
>> | lift%2Fproposals%2F0000-levity-polymorphic-
>> | lift.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89805fa4e1a3f600
>> | 8d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873534124463833
>> | &sdata=K9%2BIbsRdxplDnvRirFgrgzspyPjf3F1iZrRK5vE7q7c%3D&reserved=0
>> | >>> _______________________________________________
>> | >>> ghc-steering-committee mailing list
>> | >>> ghc-steering-committee at haskell.org
>> | >>>
>> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask
>> | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89805fa4e1a3f60
>> | 08d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687353412446383
>> | 3&sdata=37JiqdFQvu35db6WyYz6Q60jEgNQULRvhByqDUN%2FPjI%3D&reserved=0
>> | >>
>> | >>
>> | 
>> | _______________________________________________
>> | ghc-steering-committee mailing list
>> | ghc-steering-committee at haskell.org
>> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask
>> | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89805fa4e1a3f60
>> | 08d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687353412446383
>> | 3&sdata=37JiqdFQvu35db6WyYz6Q60jEgNQULRvhByqDUN%2FPjI%3D&reserved=0
> 