Re: Fixing type synonyms to Uniq(D)FM newtypes

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 wrote:

Matthew Pickering 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs