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