Fixing type synonyms to Uniq(D)FM newtypes

[Ben Gamari]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200114/12ab13e1/attachment.sig>