Fixing type synonyms to Uniq(D)FM newtypes

[Richard Eisenberg]

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?

Thanks,
Richard

> On Jan 13, 2020, at 9:10 AM, Ömer Sinan Ağacan <omeragacan at gmail.com> 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 haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs