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:niteria@gmail.com]
Sent: 06 January 2016 14:57
To: Simon Peyton Jones <simonpj@microsoft.com>
Cc: Edward Z. Yang <ezyang@mit.edu>; ghc-devs Devs <ghc-devs@haskell.org>
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 <simonpj@microsoft.com>:

|  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.