| It’s not that lift has become levity-polymorphic, rather both lift and | liftTyped are back in Lift with mutually recursive default implementations. OK, so just like (==) and (/=) in class Eq. What's the time-bomb? Does Eq suffer from it? Simon | -----Original Message----- | From: Eric Seidel <eric@seidel.io> | Sent: 05 March 2019 11:59 | To: Simon Peyton Jones <simonpj@microsoft.com> | Cc: Richard Eisenberg <rae@cs.brynmawr.edu>; ghc-steering- | committee@haskell.org | Subject: 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 <simonpj@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@haskell.org> | > | On Behalf Of Richard Eisenberg | > | Sent: 05 March 2019 03:30 | > | To: Eric Seidel <eric@seidel.io> | > | 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 <eric@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@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@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