Fixing type synonyms to Uniq(D)FM newtypes

[Ömer Sinan Ağacan]

> 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 <rae at 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 <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
>