Bartosz Well, I’m glad I wrote that Note. I think you are right on: it looks to me like an outright bug, correctly identified by the Note, that just so happens not to occur in actual code.
I’ve elaborated in this new ticket: https://ghc.haskell.org/trac/ghc/ticket/11371 Would you like to work on this? Simon From: Bartosz Nitka [mailto:[email protected]] Sent: 06 January 2016 14:57 To: Simon Peyton Jones <[email protected]> Cc: Edward Z. Yang <[email protected]>; ghc-devs Devs <[email protected]> Subject: Re: uniqAway and collisions Hello, Thank you for the paper, it helped with my understanding of how it's supposed to work. Simon, could my issue be related to your comment here: [1]? -- Note [Generating the in-scope set for a substitution] -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- If we want to substitute [a -> ty1, b -> ty2] I used to -- think it was enough to generate an in-scope set that includes -- fv(ty1,ty2). But that's not enough; we really should also take the -- free vars of the type we are substituting into! Example: -- (forall b. (a,b,x)) [a -> List b] -- Then if we use the in-scope set {b}, there is a danger we will rename -- the forall'd variable to 'x' by mistake, getting this: -- (forall x. (List b, x, x) -- Urk! This means looking at all the calls to mkOpenTvSubst.... Currently the InScope set only contains the free variables of the arguments when linting type application [2][3][4] and doesn't contain the free variables of the body that it's substituting in. The definition of substTyWith is: substTyWith :: [TyVar] -> [Type] -> Type -> Type substTyWith tvs tys = ASSERT( length tvs == length tys ) substTy (zipOpenTCvSubst tvs tys) When I changed it to include the free variables of the body my core lint error went away: substTyWith :: [TyVar] -> [Type] -> Type -> Type substTyWith tvs tys ty = ASSERT( length tvs == length tys ) substTy (extendTCvInScopeList (zipOpenTCvSubst tvs tys) (tyCoVarsOfTypeList ty)) ty It seems unlikely to me that this is the issue, since this code is very old, but I don't have a better explanation for this and a second pair of eyes would help. Thank you, Bartosz [1] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/TyCoRep.hs;cac0795af33d622e4c6ebae6ae1f206969287088$1591-1601 [2] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/coreSyn/CoreLint.hs;cac0795af33d622e4c6ebae6ae1f206969287088$788 [3] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/TyCoRep.hs;cac0795af33d622e4c6ebae6ae1f206969287088$1756 [4] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/TyCoRep.hs;cac0795af33d622e4c6ebae6ae1f206969287088$1623 2016-01-06 8:42 GMT+00:00 Simon Peyton Jones <[email protected]<mailto:[email protected]>>: | I doubt there's a bug in uniqAway; it's more likely the in scope set | is not correct. I think Edward is probably right here.
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
