<div dir="ltr"><div>In a way, if these types need to exist at all, they probably should be newtypes. That being said, I'm pretty sure that the current APIs are incomplete, so turning these into newtypes may be, in fact, quite a bit of work.</div><div><br></div><div>But if we are starting this discussion, I'd like to understand first why all these types exist at all? Why not use `UniqFM` everywhere?</div><div><br></div><div>/Arnaud<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 14, 2020 at 7:16 AM Ömer Sinan Ağacan <<a href="mailto:omeragacan@gmail.com">omeragacan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> but I still don't quite understand the motivation<br>
<br>
I give a concrete example (something that happened to me that I had to debug in<br>
runtime) in the issue I linked in my original post.<br>
<br>
> For example, delVarEnv will only work with a Var, not a Name.<br>
<br>
delVarEnv will happily accept a NameEnv in its first argument, which is the<br>
problem I was trying to describe.<br>
<br>
Ömer<br>
<br>
Richard Eisenberg <<a href="mailto:rae@richarde.dev" target="_blank">rae@richarde.dev</a>>, 14 Oca 2020 Sal, 01:55 tarihinde<br>
şunu yazdı:<br>
><br>
> 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.<br>
><br>
> Was there a different scenario that you want to avoid?<br>
><br>
> Thanks,<br>
> Richard<br>
><br>
> > On Jan 13, 2020, at 9:10 AM, Ömer Sinan Ağacan <<a href="mailto:omeragacan@gmail.com" target="_blank">omeragacan@gmail.com</a>> wrote:<br>
> ><br>
> > Hi,<br>
> ><br>
> > UniqFM and UniqDFM types are basically maps from Uniques to other stuff. Most of<br>
> > the time we don't actually map Uniques but instead map things like Vars or<br>
> > Names. For those we have types like VarEnv, NameEnv, FastStringEnv, ... which<br>
> > are defined as type synonyms to UniqFM or UniqDFM, and operations are defined<br>
> > like<br>
> ><br>
> >    extendFsEnv = addToUFM<br>
> >    extendNameEnv = addToUFM<br>
> >    extendVarEnv = addToUFM<br>
> ><br>
> > This causes problems when I have multiple Uniquables in scope and use the wrong<br>
> > one to update an environment because the program type checks and does the wrong<br>
> > thing in runtime. An example is #17667 where I did<br>
> ><br>
> >    delVarEnv env name<br>
> ><br>
> > where `name :: Name`. I shouldn't be able to remove a Name from a Var env but<br>
> > this currently type checks.<br>
> ><br>
> > Two solutions proposed:<br>
> ><br>
> > - Make these env types newtypes instead of type synonyms.<br>
> > - Add a phantom type parameter to UniqFM/UniqDFM.<br>
> ><br>
> > If you could share your opinion on how to fix this I'd like to fix this soon.<br>
> ><br>
> > Personally I prefer (1) because it looks simpler but I'd be happy with<br>
> > (2) as well.<br>
> ><br>
> > Ömer<br>
> > _______________________________________________<br>
> > ghc-devs mailing list<br>
> > <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
> > <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
><br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>