Fixing type synonyms to Uniq(D)FM newtypes
Ömer Sinan Ağacan
omeragacan at gmail.com
Tue Jan 14 06:15:54 UTC 2020
> 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.
Richard Eisenberg <rae at richarde.dev>, 14 Oca 2020 Sal, 01:55 tarihinde
> 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:
> > 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
More information about the ghc-devs