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

Tue Mar 5 16:42:25 UTC 2019

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 <eric at seidel.io>
> | Sent: 05 March 2019 11:59
> | To: Simon Peyton Jones <simonpj at microsoft.com>
> | Cc: Richard Eisenberg <rae at cs.brynmawr.edu>; ghc-steering-
> | committee at 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 at 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 <ghc-steering-committee-
> | bounces at haskell.org>
> | > | On Behalf Of Richard Eisenberg
> | > | Sent: 05 March 2019 03:30
> | > | To: Eric Seidel <eric at seidel.io>
> | > | Cc: ghc-steering-committee at 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 <eric at seidel.io> 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 <eric at 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
> | > | 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 at 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 at 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
> 
>