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

What if we simply do not have a default on the `liftTyped` method? The default is kind of dodgy anyway, as it uses the unsafe cast operator, and so an incorrect implementation of `lift` will result in an ill typed result. On Tue, Mar 5, 2019, 08:46 Simon Peyton Jones via ghc-steering-committee < ghc-steering-committee@haskell.org> wrote:

| It's not a problem with the mutually recursive definitions per se, rather | with the migration path.

Ah. Now I understand, thanks.

S

| -----Original Message----- | From: Eric Seidel | Sent: 05 March 2019 16:42 | To: Simon Peyton Jones | Cc: Richard Eisenberg ; ghc-steering- | committee@haskell.org | Subject: Re: [ghc-steering-committee] Proposal #209: Levity polymorphic | lift. Recommendation: accept | | The time-bomb is that there may exist empty Lift instances that are | *currently safe* because there's a single lift method with a default | implementation. Once you add the liftTyped method, and make the default | implementations mutually recursive, these empty instances suddenly become | unsafe. | | Eq would have the same problem if we had first defined it solely in terms | of (==), with a default implementation, and then later decided to add (/=) | and make the defaults mutually recursive. | | It's not a problem with the mutually recursive definitions per se, rather | with the migration path. | | On Tue, Mar 5, 2019, at 11:34, Simon Peyton Jones wrote: | > | 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 | > | Sent: 05 March 2019 11:59 | > | To: Simon Peyton Jones | > | Cc: Richard Eisenberg ; 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 | bounces@haskell.org> | > | > | 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 | > | > _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee