Fixing type synonyms to Uniq(D)FM newtypes

Richard Eisenberg rae at
Tue Jan 14 11:29:47 UTC 2020

One advantage of the phantom-parameter approach is that it allows for nice polymorphism.

> lookupEnv :: Uniquable dom => UniqFM dom rng -> dom -> Maybe rng

Now, we don't need lookupVarEnv separately from lookupNameEnv, but we get the type-checking for free.

I agree with Ben about the fact that newtypes have their own advantages.

I don't have much of an opinion, in the end.


> On Jan 14, 2020, at 10:31 AM, Ben Gamari <ben at> wrote:
> Matthew Pickering <matthewtpickering at> writes:
>> Can someone explain the benefit of the newtype wrappers over the
>> phantom type parameter approach?
>> In my mind adding a phantom type parameter to `UniqFM` solves the
>> issue entirely but will result in less code churn and follows the
>> example from the existing map data types from containers.
> I would say the same of newtype wrappers; afterall, we already have a
> convention of using the "specialised" type synonyms and their functions
> instead of UniqFM directly where possible. Turning VarEnv, etc. into
> newtypes likely touch little code outside of the modules where they are
> defined.
> Which approach is preferable is really a question of what degree of
> encapsulation we want. The advantage of making, e.g., VarEnv a newtype
> is that our use of Uniques remains an implementation detail (which it
> is, in my opinion). We are then in principle free to change the
> representation of VarEnv down the road.
> Of course, in practice it is hard to imagine GHC moving away from
> uniques for things like VarEnv. However, properly encapsulating them
> seems like good engineering practice and incurs very little cost
> (especially given our current conventions).
> Cheers,
> - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at

More information about the ghc-devs mailing list