Unique as special boxing type & hidden constructors

[Simon Marlow]

On 04/09/2014 13:25, p.k.f.holzenspies at utwente.nl wrote:
> Dear Simon,
>
> The point is to have
>
> newtype Unique = Unique Int

Yes, I misunderstood, thanks!

> 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!

There are compiler performance tests in testsuite/tests/perf/compiler. 
They will only fail if the performance gets worse by 10% or so 
(depending on the test), so instead of checking for failure just run the 
tests manually and compare the allocation values before and after your 
change (remember to save a copy of the original compiler binary so that 
you can do comparisons).

Another way to test performance is to compile a large module, e.g. 
nofib/spectral/simple/Main.hs is a good one.

Cheers,
Simon


> Regards,
> Philip
>
>
>
> ________________________________________
> From: Simon Marlow <marlowsd at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>