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 <omeraga...@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@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
