Fixing type synonyms to Uniq(D)FM newtypes
Richard Eisenberg
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?
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
More information about the ghc-devs
mailing list