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

[Simon Peyton Jones]

I'm supportive too.  But, as I say on the proposal thread, before this lands we should decide about https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0026-explicit-specificity.rst.



I came across another pretty convincing use-case for explicit specificity, in new draft paper "Higher-order Type-level Programming in Haskell".  Will publish a link to it shortly.  But in brief we have a function.

hMap ::  forall {m :: Matchability}

                (c :: * -> Constraint)

                (f :: * ->m *) as.

         All as c => (forall a. c a => a -> f a) -> HList as -> HList (Map f as)


Where the ‘m’ parameter is entirely forced by the ‘f’ parameter.  So we’d end up writing

Hmap @_ @Db @DbUser
a lot.  That “@_” is a bit silly



Simon



-----Original Message-----
From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Eric Seidel
Sent: 02 March 2019 21:42
To: ghc-steering-committee at haskell.org
Subject: [ghc-steering-committee] Proposal #209: Levity polymorphic lift. Recommendation: accept



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://github.com/harpocrates/ghc-proposals/blob/levity-polymorphic-lift/proposals/0000-levity-polymorphic-lift.rst

_______________________________________________

ghc-steering-committee mailing list

ghc-steering-committee at haskell.org<mailto: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/20190304/1f6a5dc5/attachment-0001.html>