Ah yes, I believe you're referring to https://ghc.haskell.org/
trac/ghc/ticket/8767 (which I wasn't aware of). And yes, I do believe we'd
need some combination of QuantifiedContexts/ImplicationConstraints to fully
support everything.
But in any case, don't let this discussion side-track too much f
This a use case for ImplicationConstraints, or what
On Jun 6, 2017 19:02, "David Feuer" wrote:
> Edward Kmett has explained that this isn't sufficient when things go
> higher order. His suggested improvement is
>
> liftCoercion :: Maybe (Coercion a b -> Coercion (f a) (f b))
>
>
>
> David Fe
Edward Kmett has explained that this isn't sufficient when things go higher
order. His suggested improvement is
liftCoercion :: Maybe (Coercion a b -> Coercion (f a) (f b))
David FeuerWell-Typed, LLP
Original message From: Ryan Scott
Date: 6/6/17 1:41 PM (GMT-05:00) To:
Hrm. It's a shame that supporting this map/coerce RULE causes such pain.
This makes me wonder: can we get rid of this RULE? Eric Mertens pointed out
a trick [1] that's used in the profunctors library to make mapping coerce
over certain Profunctors more efficient. To adapt this trick for Functor,
w
Elm has a interesting take on this: a collection of all error messages (
https://github.com/elm-lang/error-message-catalog).
I created an empty repo (
https://github.com/bollu/hask-error-messages-catalog) and shot an email to
haskell-cafe asking for examples where GHC generates unintuitive error
m
