Re (1) I think this is a historical.  A newtype wrapping an Int should be fine. 
 I'd be ok with that change.

Re (2), I think your question is: why does module Unique export the data type 
Unique abstractly, rather than exporting both the data type and its 
constructor.  No deep reason here, but it guarantees that you can only *make* a 
unique from an Int by calling 'mkUniqueGrimily', which signals clearly that 
something fishy is going on.  And rightly so!

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of 
p.k.f.holzensp...@utwente.nl
Sent: 15 August 2014 11:53
To: ghc-devs@haskell.org
Subject: Unique as special boxing type & hidden constructors


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

Reply via email to