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

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 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 | On Behalf Of Richard Eisenberg | Sent: 05 March 2019 03:30 | To: Eric Seidel | Cc: ghc-steering-committee@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 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 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@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@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