You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of GHC 8.10.7, the base library contains type class instances generated via GeneralizedNewtypeDeriving. Given newtype X a = X a, a type class C e with a method f :: t gets translated like
instanceCa=>C (Xa) where
f =GHC.Prim.coerce (f) ::t'
where t' is obtained by substituting X a for e in t.
For example, the following code:
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
newtypeApfa=Ap{getAp::fa}deriving (Functor)
The code that hs-to-coq generates for fmap looks like:
#[local] Definition Functor__Ap_fmap {inst_f : Type -> Type} `{GHC.Base.Functor
inst_f}
: forall {a : Type},
forall {b : Type}, (a -> b) -> Ap inst_f a -> Ap inst_f b :=
fun {a : Type} {b : Type} =>
GHC.Prim.coerce (GHC.Base.fmap) : (forall {a
: GHC.Prim.TYPE GHC.Types.LiftedRep}
{b : GHC.Prim.TYPE GHC.Types.LiftedRep},
(a -> b) -> Ap inst_f a -> Ap inst_f b).
But this doesn't typecheck (or, more precisely, Coq will fail to find a Coercible instance): the coerce is ascribed a fully-polymorphic type, but the type arguments have already been "eaten" by the fun construct.
The code for generating these instances is in HsToCoq.ConvertHaskell.Declarations.Instances. The fundamental problem is that this code assumes that the RHS of a typeclass instance method is never polymorphic, which is not true in this case.
In c86c82d, I implemented the "bad" solution, which is to heuristically detect methods that look like they were generated by GeneralizedNewtypeDeriving and throw away the ascription. As I see it, the "correct" solution would be to infer the type of the RHS and unify it against the method's expected type.
The text was updated successfully, but these errors were encountered:
As of GHC 8.10.7, the base library contains type class instances generated via
GeneralizedNewtypeDeriving
. Givennewtype X a = X a
, a type classC e
with a methodf :: t
gets translated likewhere
t'
is obtained by substitutingX a
fore
int
.For example, the following code:
generates the following instance:
The code that hs-to-coq generates for
fmap
looks like:But this doesn't typecheck (or, more precisely, Coq will fail to find a
Coercible
instance): thecoerce
is ascribed a fully-polymorphic type, but the type arguments have already been "eaten" by thefun
construct.The code for generating these instances is in
HsToCoq.ConvertHaskell.Declarations.Instances
. The fundamental problem is that this code assumes that the RHS of a typeclass instance method is never polymorphic, which is not true in this case.In c86c82d, I implemented the "bad" solution, which is to heuristically detect methods that look like they were generated by
GeneralizedNewtypeDeriving
and throw away the ascription. As I see it, the "correct" solution would be to infer the type of the RHS and unify it against the method's expected type.The text was updated successfully, but these errors were encountered: