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

Tue Mar 5 17:37:19 UTC 2019

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

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 <
ghc-steering-committee at 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 <eric at seidel.io>
> | Sent: 05 March 2019 16:42
> | 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
> |
> | 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
> | >
> | >
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190305/b62ffc0d/attachment-0001.html>