[ghc-steering-committee] Proposal #209: Levity polymorphic lift. Recommendation: accept
Simon Peyton Jones
simonpj at microsoft.com
Mon Mar 4 12:32:13 UTC 2019
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>
More information about the ghc-steering-committee
mailing list