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 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/pr... _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

That's true, thank you for reminding me of our previous discussion about this issue. I recall suggesting earlier a one-off error for empty Lift instances. It's kludgy, but easy to implement and deploy since TH is bundled with GHC. And it makes the problem go away entirely. This solution seems more compelling than it did before, since we now have a good reason for wanting both methods in the class. Eric On Mon, Mar 4, 2019, at 22:30, Richard Eisenberg wrote:

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://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 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/pr... _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

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

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

On Mar 5, 2019, at 12:37 PM, Iavor Diatchki wrote:

What if we simply do not have a default on the `liftTyped` method?

That might work. This means that old hand-written instances for Lift will be broken -- but we've agreed that's OK. New (generated) instances will use liftTyped. Is it possible to write liftTyped in a generic way, like the way the old lift had a generic default? That might solve all the problems at once. Richard

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 mailto: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 mailto:eric@seidel.io> | Sent: 05 March 2019 16:42 | To: Simon Peyton Jones mailto:simonpj@microsoft.com> | Cc: Richard Eisenberg mailto:rae@cs.brynmawr.edu>; ghc-steering- | committee@haskell.org mailto: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 mailto:eric@seidel.io> | > | Sent: 05 March 2019 11:59 | > | To: Simon Peyton Jones mailto:simonpj@microsoft.com> | > | Cc: Richard Eisenberg mailto:rae@cs.brynmawr.edu>; ghc-steering- | > | committee@haskell.org mailto: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 mailto: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 mailto:bounces@haskell.org> | > | > | On Behalf Of Richard Eisenberg | > | > | Sent: 05 March 2019 03:30 | > | > | To: Eric Seidel mailto:eric@seidel.io> | > | > | Cc: ghc-steering-committee@haskell.org mailto: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 mailto:eric@seidel.io> wrote: | > | > | > | > | > | > I believe you're thinking of | > | > | | > | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co 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 http://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 mailto: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 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 http://40microsoft.com/%7C179fc89805fa4e1a3f600 | > | > | | > | | 8d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873534124463833 | > | > | | > | | &sdata=K9%2BIbsRdxplDnvRirFgrgzspyPjf3F1iZrRK5vE7q7c%3D&reserved=0 | > | > | >>> _______________________________________________ | > | > | >>> ghc-steering-committee mailing list | > | > | >>> ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org | > | > | >>> | > | > | | > | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask | > | > | ell.org http://ell.org/%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | > | > | | > | | committee&data=02%7C01%7Csimonpj%40microsoft.com http://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 mailto:ghc-steering-committee@haskell.org | > | > | | > | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask | > | > | ell.org http://ell.org/%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | > | > | | > | | committee&data=02%7C01%7Csimonpj%40microsoft.com http://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 mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

On Mar 7, 2019, at 10:27 PM, Eric Seidel mailto:eric@seidel.io> wrote:

I imagine we could get away with

default liftTyped :: (r ~ 'LiftedRep, Data t) => t -> Q (TExp t) liftTyped = unsafeTExpCoerce . liftData

Sadly, this won't work. GHC just isn't clever enough. The problem is that, for (Data t) to be well-typed, we need (r ~ LiftedRep). This means that the typedness of one constraint depends on another. The internal language can do this fine, but type inference isn't up to the challenge. We'll get there some day. But I think this way is a dead-end for now. So it sounds (to me) that the best way forward is to remove the default implementation of liftTyped altogether.... Richard

HI, Am Samstag, den 16.03.2019, 10:40 -0400 schrieb Eric Seidel:

Too bad. It sounds like we agree then that removing the default implementation is the best option we have. I've proposed that on GitHub and will approve the modified proposal assuming there aren't any last objections.

modified and approved. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/