<div dir="ltr">Hello,<div><br></div><div>Thank you for the paper, it helped with my understanding of how it's supposed to work.</div><div>Simon, could my issue be related to your comment here: [1]?</div><div><br></div><div><div>-- Note [Generating the in-scope set for a substitution]</div><div>-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</div><div>-- If we want to substitute [a -> ty1, b -> ty2] I used to </div><div>-- think it was enough to generate an in-scope set that includes</div><div>-- fv(ty1,ty2).  But that's not enough; we really should also take the</div><div>-- free vars of the type we are substituting into!  Example:</div><div>--  (forall b. (a,b,x)) [a -> List b]</div><div>-- Then if we use the in-scope set {b}, there is a danger we will rename</div><div>-- the forall'd variable to 'x' by mistake, getting this:</div><div>--  (forall x. (List b, x, x)</div><div>-- Urk!  This means looking at all the calls to mkOpenTvSubst....</div></div><div><br></div><div>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.</div><div><br></div><div>The definition of substTyWith is:</div><div><br></div><div><div>substTyWith :: [TyVar] -> [Type] -> Type -> Type</div></div><div><div>substTyWith tvs tys = ASSERT( length tvs == length tys )</div><div>                      substTy (zipOpenTCvSubst tvs tys)</div></div><div><br></div><div><br></div><div>When I changed it to include the free variables of the body my core lint error went away:</div><div><br></div><div><div>substTyWith :: [TyVar] -> [Type] -> Type -> Type</div><div>substTyWith tvs tys ty = ASSERT( length tvs == length tys )</div><div>                      substTy (extendTCvInScopeList (zipOpenTCvSubst tvs tys) (tyCoVarsOfTypeList ty)) ty</div></div><div><br></div><div><br></div><div>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.</div><div><br></div><div>Thank you,</div><div>Bartosz</div><div><br></div><div>[1] <a href="https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/TyCoRep.hs;cac0795af33d622e4c6ebae6ae1f206969287088$1591-1601">https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/TyCoRep.hs;cac0795af33d622e4c6ebae6ae1f206969287088$1591-1601</a></div><div>[2] <a href="https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/coreSyn/CoreLint.hs;cac0795af33d622e4c6ebae6ae1f206969287088$788">https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/coreSyn/CoreLint.hs;cac0795af33d622e4c6ebae6ae1f206969287088$788</a></div><div>[3] <a href="https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/TyCoRep.hs;cac0795af33d622e4c6ebae6ae1f206969287088$1756">https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/TyCoRep.hs;cac0795af33d622e4c6ebae6ae1f206969287088$1756</a></div><div>[4] <a href="https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/TyCoRep.hs;cac0795af33d622e4c6ebae6ae1f206969287088$1623">https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/TyCoRep.hs;cac0795af33d622e4c6ebae6ae1f206969287088$1623</a></div><div><br><div class="gmail_extra"><br><div class="gmail_quote">2016-01-06 8:42 GMT+00:00 Simon Peyton Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">|  I doubt there's a bug in uniqAway; it's more likely the in scope set<br>
|  is not correct.<br>
<br>
</span>I think Edward is probably right here.<span class=""><br></span></blockquote></div></div></div></div>