Unique as special boxing type & hidden constructors

[Edward Z. Yang]

Newtype of Int, to be clear.

Edward

Excerpts from Simon Marlow's message of 2014-09-04 11:49:39 +0200:
> FastInt = Int#, so newtype doesn't work here.
> 
> Cheers,
> Simon
> 
> On 15/08/2014 14:01, Edward Z. Yang wrote:
> > The definition dates back to 1996, so it seems plausible that
> > newtype is the way to go now.
> >
> > Edward
> >
> > Excerpts from p.k.f.holzenspies's message of 2014-08-15 11:52:47 +0100:
> >> Dear all,
> >>
> >>
> >> I'm working with Alan to instantiate everything for Data.Data, so that we can do better SYB-traversals (which should also help newcomers significantly to get into the GHC code base). Alan's looking at the AST types, I'm looking at the basic types in the compiler.
> >>
> >> Right now, I'm looking at Unique and two questions come up:
> >>
> >>> data Unique = MkUnique FastInt
> >>
> >>
> >> 1) As someone already commented: Is there a specific reason (other than history) that this isn't simply a newtype around an Int? If we're boxing anyway, we may as well use the default Int boxing and newtype-coerce to the specific purpose of Unique, no?
> >>
> >>
> >> 2) As a general question for GHC hacking style; what is the reason for hiding the constructors in the first place?
> >>
> >> I understand about abstraction and there are reasons for hiding, but there's a "public GHC API" and then there are all these modules that people can import at their own peril. Nothing is guaranteed about their consistency from version to version of GHC. I don't really see the point about hiding constructors (getting in the way of automatically deriving things) and then giving extra functions like (in the case of Unique):
> >>
> >>> getKeyFastInt (MkUnique x) = x
> >>
> >>> mkUniqueGrimily x = MkUnique (iUnbox x)
> >>
> >>
> >> I would propose to just make Unique a newtype for an Int and making the constructor visible.
> >>
> >>
> >> Regards,
> >>
> >> Philip
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >