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@haskell.org> On Behalf Of Eric Seidel
Sent: 02 March 2019 21:42
To: ghc-steering-committee@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
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee