Fixing type synonyms to Uniq(D)FM newtypes
rae at richarde.dev
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 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
> 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).
> - Ben
> ghc-devs mailing list
> ghc-devs at haskell.org
More information about the ghc-devs