Fixing type synonyms to Uniq(D)FM newtypes

Richard Eisenberg rae at
Mon Jan 13 22:55:02 UTC 2020

I'd be fine with making these newtypes, but I still don't quite understand the motivation. Note that the specialized functions for the different instances of UniqFM all have type signatures. For example, delVarEnv will only work with a Var, not a Name.

Was there a different scenario that you want to avoid?


> On Jan 13, 2020, at 9:10 AM, Ömer Sinan Ağacan <omeragacan at> wrote:
> Hi,
> UniqFM and UniqDFM types are basically maps from Uniques to other stuff. Most of
> the time we don't actually map Uniques but instead map things like Vars or
> Names. For those we have types like VarEnv, NameEnv, FastStringEnv, ... which
> are defined as type synonyms to UniqFM or UniqDFM, and operations are defined
> like
>    extendFsEnv = addToUFM
>    extendNameEnv = addToUFM
>    extendVarEnv = addToUFM
> This causes problems when I have multiple Uniquables in scope and use the wrong
> one to update an environment because the program type checks and does the wrong
> thing in runtime. An example is #17667 where I did
>    delVarEnv env name
> where `name :: Name`. I shouldn't be able to remove a Name from a Var env but
> this currently type checks.
> Two solutions proposed:
> - Make these env types newtypes instead of type synonyms.
> - Add a phantom type parameter to UniqFM/UniqDFM.
> If you could share your opinion on how to fix this I'd like to fix this soon.
> Personally I prefer (1) because it looks simpler but I'd be happy with
> (2) as well.
> Ömer
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at

More information about the ghc-devs mailing list