Fixing type synonyms to Uniq(D)FM newtypes

[Richard Eisenberg]

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.

Richard

> On Jan 14, 2020, at 10:31 AM, Ben Gamari <ben at smart-cactus.org> wrote:
> 
> Matthew Pickering <matthewtpickering at gmail.com> 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 haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs