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 <b...@smart-cactus.org> wrote: > > Matthew Pickering <matthewtpicker...@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@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
