<div dir="auto">What if we simply do not have a default on the `liftTyped` method? <div dir="auto"><br></div><div dir="auto">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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 5, 2019, 08:46 Simon Peyton Jones via ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">| It's not a problem with the mutually recursive definitions per se, rather<br>
| with the migration path.<br>
<br>
Ah. Now I understand, thanks.<br>
<br>
S<br>
<br>
| -----Original Message-----<br>
| From: Eric Seidel <<a href="mailto:eric@seidel.io" target="_blank" rel="noreferrer">eric@seidel.io</a>><br>
| Sent: 05 March 2019 16:42<br>
| To: Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank" rel="noreferrer">simonpj@microsoft.com</a>><br>
| Cc: Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu" target="_blank" rel="noreferrer">rae@cs.brynmawr.edu</a>>; ghc-steering-<br>
| <a href="mailto:committee@haskell.org" target="_blank" rel="noreferrer">committee@haskell.org</a><br>
| Subject: Re: [ghc-steering-committee] Proposal #209: Levity polymorphic<br>
| lift. Recommendation: accept<br>
| <br>
| The time-bomb is that there may exist empty Lift instances that are<br>
| *currently safe* because there's a single lift method with a default<br>
| implementation. Once you add the liftTyped method, and make the default<br>
| implementations mutually recursive, these empty instances suddenly become<br>
| unsafe.<br>
| <br>
| Eq would have the same problem if we had first defined it solely in terms<br>
| of (==), with a default implementation, and then later decided to add (/=)<br>
| and make the defaults mutually recursive.<br>
| <br>
| It's not a problem with the mutually recursive definitions per se, rather<br>
| with the migration path.<br>
| <br>
| On Tue, Mar 5, 2019, at 11:34, Simon Peyton Jones wrote:<br>
| > | It’s not that lift has become levity-polymorphic, rather both lift and<br>
| > | liftTyped are back in Lift with mutually recursive default<br>
| implementations.<br>
| ><br>
| > OK, so just like (==) and (/=) in class Eq. What's the time-bomb?<br>
| > Does Eq suffer from it?<br>
| ><br>
| > Simon<br>
| ><br>
| > | -----Original Message-----<br>
| > | From: Eric Seidel <<a href="mailto:eric@seidel.io" target="_blank" rel="noreferrer">eric@seidel.io</a>><br>
| > | Sent: 05 March 2019 11:59<br>
| > | To: Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank" rel="noreferrer">simonpj@microsoft.com</a>><br>
| > | Cc: Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu" target="_blank" rel="noreferrer">rae@cs.brynmawr.edu</a>>; ghc-steering-<br>
| > | <a href="mailto:committee@haskell.org" target="_blank" rel="noreferrer">committee@haskell.org</a><br>
| > | Subject: Re: [ghc-steering-committee] Proposal #209: Levity polymorphic<br>
| > | lift. Recommendation: accept<br>
| > |<br>
| > | It’s not that lift has become levity-polymorphic, rather both lift and<br>
| > | liftTyped are back in Lift with mutually recursive default<br>
| implementations.<br>
| > |<br>
| > | Sent from my iPhone<br>
| > |<br>
| > | > On Mar 5, 2019, at 03:13, Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank" rel="noreferrer">simonpj@microsoft.com</a>><br>
| > | wrote:<br>
| > | ><br>
| > | > | > data Foo<br>
| > | > | > deriving Data<br>
| > | > | > instance Lift Foo<br>
| > | > |<br>
| > | > | But after this proposal, it will still be accepted **but will<br>
| loop**.<br>
| > | That<br>
| > | > | is, the instance silently becomes a bomb waiting to maim poor<br>
| clients<br>
| > | with<br>
| > | > | an obscure compile-time hang.<br>
| > | ><br>
| > | > Can you remind us why making Lift levit-polymorphic causes this<br>
| change in<br>
| > | looping behaviour?<br>
| > | ><br>
| > | > Simon<br>
| > | ><br>
| > | > | -----Original Message-----<br>
| > | > | From: ghc-steering-committee <ghc-steering-committee-<br>
| > | <a href="mailto:bounces@haskell.org" target="_blank" rel="noreferrer">bounces@haskell.org</a>><br>
| > | > | On Behalf Of Richard Eisenberg<br>
| > | > | Sent: 05 March 2019 03:30<br>
| > | > | To: Eric Seidel <<a href="mailto:eric@seidel.io" target="_blank" rel="noreferrer">eric@seidel.io</a>><br>
| > | > | Cc: <a href="mailto:ghc-steering-committee@haskell.org" target="_blank" rel="noreferrer">ghc-steering-committee@haskell.org</a><br>
| > | > | Subject: Re: [ghc-steering-committee] Proposal #209: Levity<br>
| polymorphic<br>
| > | > | lift. Recommendation: accept<br>
| > | > |<br>
| > | > | Thanks, Eric.<br>
| > | > |<br>
| > | > | So, if we restore lift (and have it be defined in terms of<br>
| liftTyped)<br>
| > | to<br>
| > | > | the Lift class, then we potentially have a problem. This is allowed<br>
| > | today<br>
| > | > | (and it works well):<br>
| > | > |<br>
| > | > | > data Foo<br>
| > | > | > deriving Data<br>
| > | > | > instance Lift Foo<br>
| > | > |<br>
| > | > | But after this proposal, it will still be accepted **but will<br>
| loop**.<br>
| > | That<br>
| > | > | is, the instance silently becomes a bomb waiting to maim poor<br>
| clients<br>
| > | with<br>
| > | > | an obscure compile-time hang. Because of the MINIMAL pragma, there<br>
| will<br>
| > | be<br>
| > | > | a warning. So perhaps we decide that the warning is enough of a<br>
| > | deterrent<br>
| > | > | and to allow this strange back-compat story.<br>
| > | > |<br>
| > | > | On the other hand, if we remove lift from the class, then the above<br>
| > | code<br>
| > | > | fails with a "liftTyped is not defined" error. That's quite easy to<br>
| > | > | pinpoint.<br>
| > | > |<br>
| > | > | I'm not wholly against this proposal at all -- indeed, it's a nice<br>
| > | > | application of levity polymorphism -- but I think there is a real<br>
| > | drawback<br>
| > | > | here worth debating.<br>
| > | > |<br>
| > | > | Richard<br>
| > | > |<br>
| > | > | > On Mar 4, 2019, at 10:19 PM, Eric Seidel <<a href="mailto:eric@seidel.io" target="_blank" rel="noreferrer">eric@seidel.io</a>> wrote:<br>
| > | > | ><br>
| > | > | > I believe you're thinking of<br>
| > | > |<br>
| > |<br>
| <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co" rel="noreferrer noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co</a><br>
| > | > | m%2Fghc-proposals%2Fghc-<br>
| > | > |<br>
| > |<br>
| proposals%2Fpull%2F175&data=02%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer noreferrer" target="_blank">40microsoft.com</a>%7C179fc89<br>
| > | > |<br>
| > |<br>
| 805fa4e1a3f6008d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6368<br>
| > | > |<br>
| > |<br>
| 73534124463833&sdata=WUd8z511ysFVYxvhdpYCtw0useZOtOq37VANULn%2BHd8%3D&a<br>
| > | > | mp;reserved=0. The PR has been marked accepted, but it seems it<br>
| didn't<br>
| > | get<br>
| > | > | merged.<br>
| > | > | ><br>
| > | > | > On Mon, Mar 4, 2019, at 22:16, Richard Eisenberg wrote:<br>
| > | > | >> I recall a discussion in another proposal about the Lift class<br>
| and<br>
| > | > | >> removing the lift function. This was for a good reason (I think<br>
| it<br>
| > | > | >> stopped silent, terrible breakage). Does anyone remember where<br>
| that<br>
| > | > | >> conversation took place? A quick search didn't find an accepted<br>
| > | > | >> proposal about the Lift class.<br>
| > | > | >><br>
| > | > | >> Thanks,<br>
| > | > | >> Richard<br>
| > | > | >><br>
| > | > | >>> On Mar 2, 2019, at 4:41 PM, Eric Seidel <<a href="mailto:eric@seidel.io" target="_blank" rel="noreferrer">eric@seidel.io</a>> wrote:<br>
| > | > | >>><br>
| > | > | >>> Hi everyone,<br>
| > | > | >>><br>
| > | > | >>> This proposal[1] makes the `lift` and `liftTyped` methods of<br>
| the<br>
| > | `Lift`<br>
| > | > | class levity-polymorphic, which allows us to write proper `Lift`<br>
| > | instances<br>
| > | > | for unlifted types. It would also allow GHC to remove the special<br>
| logic<br>
| > | > | that currently supports lifting records with unlifted fields.<br>
| > | > | >>><br>
| > | > | >>> The main downside is the potential for breakage since `lift<br>
| @Foo`<br>
| > | would<br>
| > | > | now fix the RuntimeRep parameter rather than the `a`. This is<br>
| > | unfortunate,<br>
| > | > | but I doubt it will show up much. It also unfortunately requires<br>
| making<br>
| > | > | both `lift` and `liftTyped` methods, when we had just decided to<br>
| > | extract<br>
| > | > | `lift` from the class.<br>
| > | > | >>><br>
| > | > | >>> I recommend accepting the proposal.<br>
| > | > | >>><br>
| > | > | >>> Thanks!<br>
| > | > | >>> Eric<br>
| > | > | >>><br>
| > | > | >>> [1]:<br>
| > | > |<br>
| > |<br>
| <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co" rel="noreferrer noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co</a><br>
| > | > | m%2Fharpocrates%2Fghc-proposals%2Fblob%2Flevity-polymorphic-<br>
| > | > | lift%2Fproposals%2F0000-levity-polymorphic-<br>
| > | > |<br>
| > |<br>
| lift.rst&data=02%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer noreferrer" target="_blank">40microsoft.com</a>%7C179fc89805fa4e1a3f600<br>
| > | > |<br>
| > |<br>
| 8d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873534124463833<br>
| > | > |<br>
| > |<br>
| &sdata=K9%2BIbsRdxplDnvRirFgrgzspyPjf3F1iZrRK5vE7q7c%3D&reserved=0<br>
| > | > | >>> _______________________________________________<br>
| > | > | >>> ghc-steering-committee mailing list<br>
| > | > | >>> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank" rel="noreferrer">ghc-steering-committee@haskell.org</a><br>
| > | > | >>><br>
| > | > |<br>
| > |<br>
| <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask" rel="noreferrer noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask</a><br>
| > | > | <a href="http://ell.org" rel="noreferrer noreferrer" target="_blank">ell.org</a>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-<br>
| > | > |<br>
| > |<br>
| committee&data=02%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer noreferrer" target="_blank">40microsoft.com</a>%7C179fc89805fa4e1a3f60<br>
| > | > |<br>
| > |<br>
| 08d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687353412446383<br>
| > | > |<br>
| > |<br>
| 3&sdata=37JiqdFQvu35db6WyYz6Q60jEgNQULRvhByqDUN%2FPjI%3D&reserved=0<br>
| > | > | >><br>
| > | > | >><br>
| > | > |<br>
| > | > | _______________________________________________<br>
| > | > | ghc-steering-committee mailing list<br>
| > | > | <a href="mailto:ghc-steering-committee@haskell.org" target="_blank" rel="noreferrer">ghc-steering-committee@haskell.org</a><br>
| > | > |<br>
| > |<br>
| <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask" rel="noreferrer noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask</a><br>
| > | > | <a href="http://ell.org" rel="noreferrer noreferrer" target="_blank">ell.org</a>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-<br>
| > | > |<br>
| > |<br>
| committee&data=02%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer noreferrer" target="_blank">40microsoft.com</a>%7C179fc89805fa4e1a3f60<br>
| > | > |<br>
| > |<br>
| 08d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687353412446383<br>
| > | > |<br>
| > |<br>
| 3&sdata=37JiqdFQvu35db6WyYz6Q60jEgNQULRvhByqDUN%2FPjI%3D&reserved=0<br>
| ><br>
| ><br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" rel="noreferrer">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>