> but I still don't quite understand the motivation I give a concrete example (something that happened to me that I had to debug in runtime) in the issue I linked in my original post.
> For example, delVarEnv will only work with a Var, not a Name. delVarEnv will happily accept a NameEnv in its first argument, which is the problem I was trying to describe. Ömer Richard Eisenberg <r...@richarde.dev>, 14 Oca 2020 Sal, 01:55 tarihinde şunu yazdı: > > 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
