Fixing type synonyms to Uniq(D)FM newtypes
ben at smart-cactus.org
Tue Jan 14 10:31:12 UTC 2020
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 487 bytes
Desc: not available
More information about the ghc-devs