Ömer Sinan Ağacan <omeraga...@gmail.com> writes: > 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. > At first I was a bit confused at how this could possibly typecheck. Afterall, delVarEnv has type,
VarEnv a -> Var -> VarEnv a
which seems quite reasonable and should correctly reject the application
to a Name as given in Omer's example. However, the mistake in #17667
is actually that he wrote,
delVarEnv env name
instead of
delNameEnv env (varName var)
That is, because `VarEnv a ~ NameEnv a` one can easily mix up a
NameEnv with a VarEnv and not get a compile-time error. I can see how
this could be a nasty bug to track down.
> Two solutions proposed:
>
> - Make these env types newtypes instead of type synonyms.
> - Add a phantom type parameter to UniqFM/UniqDFM.
>
IIRC this has been suggested before. I, for one, see the value in this
and certainly wouldn't be opposed to either of these options, although
would weakly favor the former over the latter.
Cheers,
- Ben
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
