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
> > [email protected]
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs

Reply via email to