Fixing type synonyms to Uniq(D)FM newtypes
rae at richarde.dev
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 gmail.com> wrote:
> 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
> 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.
> ghc-devs mailing list
> ghc-devs at haskell.org
More information about the ghc-devs