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

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