Hello Simon, I was about to send an improved version of D1801, I will do that once I rebase past your patch (there's a small overlap with what I've done). D1820 is ready for review. I have a patch coming for piResultTys [1] where the FVs of ty are not in the in_scope set. I've also looked at a similar problem in lint_app [2], but the fix I have is a bit awkward, so I will probably need some input from you. Both of them are blocking #11360 and I want to get it unblocked as soon as possible to continue determinism work. I'm aware of substTys being currently unchecked, I didn't want to introduce substTysUnchecked just yet, as there already are more than 30 occurrences of substTyUnchecked. But maybe I should push uncheckedness as far up as possible, do you think it's worth to do it now? Do you want me to do the renaming? Cheers, Bartosz [1] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/T... [2] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/coreSyn... 2016-01-26 10:55 GMT+00:00 Simon Peyton Jones <simonpj@microsoft.com>:
Bartosz
How are you getting on with tidying up substitutions.
I’ve done a bit in that direction myself:
commit 1c6d70c2121fd1126fcc2458bdbcc856e19598c2
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date: Tue Jan 26 09:37:06 2016 +0000
Kill off zipTopTCvSubst in favour of zipOpenTCvSubst
But there is more to do.
In particular, I note that * substTys is not checked* – but neither is it called substTysUnchecked. It should be! That will show up a bunch more cases, I think.
Another particular thing, arising from my patch, is that *we can now do some renaming*
· zipOpenTCvSubst -> zipTvSubst (It only deals with tyvars)
· zipOpenTCvSubstCoVars -> zipCvSubst (it only deals with covars)
· zipOpenTCvSubstBinders -> zipTyBinderSubst (it only deals with TyBinders, not covars)
I guess you’ll want to do similar things for the “mk” variants.
Anyway: good for you! Let me know if you need help.
Simon