Dear Simon, The point is to have
newtype Unique = Unique Int where we use the boxing of Int, instead of creating our own boxing. Actually, it seems useful to move to newtype Unique = Unique Word (see other discussions about unnecessary signedness). I've been working on this (although only as a side-project, so progress is very slow) and I've discovered a lot of API-out-of-sync-ness; there are comments stating we don't export mkUnique, so that we can keep track of all the Chars we use. Unfortunately, we *do* export mkUnique from Unique and we do *not* have consistent use of Chars everywhere. I'm working to replace the Char-mechanism with a (rather straightforward) sum-type UniqueDomain. This should also help get a more consistent treatment of serialisation (the one in the module Unique is *slightly* different from the one in BinIface). I'm still not quite sure how to do the performance tests on the actual compilation (i.e. runtime of GHC itself). If anything, moving Uniques to a higher abstraction (coerced boxed values, instead of manually boxed stuff) is actually a good litmus test of how far GHC's optimisations have come since '96 ;) If you have any more input, especially on performance stuff (what would be the worst acceptable performance hit and measured on what, for example), it would be *very* welcome! Regards, Philip ________________________________________ From: Simon Marlow <marlo...@gmail.com> Sent: 04 September 2014 11:49 To: Edward Z. Yang; Holzenspies, P.K.F. (EWI) Cc: ghc-devs Subject: Re: Unique as special boxing type & hidden constructors 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@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
