Johan Yes broadly that looks like the right kind of thing.
I think it'd be better to look more like "can_unbox". So first check for a product tycon (ie one data constructor), then deal with newtypes, and *then* do something different, namely check whether the (single) data con has zero or one fields, and recurse. Since it's all flag-controlled you could push and I can subsequently edit Simoin | -----Original Message----- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell- | users-boun...@haskell.org] On Behalf Of Johan Tibell | Sent: 29 November 2012 18:13 | To: glasgow-haskell-users | Subject: Re: Computing the final representation type of a TyCon (Was: | Unpack primitive types by default in data) | | Hi, | | I've created an initial implementation that seems to work. I'd | appreciate it if someone could review the code (it's short!) to tell me | if it's sane, can be improved, etc: | | https://github.com/tibbe/ghc/commit/6b44024173eae3029b7b43f7cc9fc7d9d801 | c367 | | On Thu, Nov 29, 2012 at 12:27 AM, Johan Tibell <johan.tib...@gmail.com> | wrote: | > I've decided to try to implement the proposal included in the end of | > this message. To do so I need to write a function | > | > hasPointerSizedRepr :: TyCon -> Bool | > | > This function would check that that the TyCon is either | > | > * a newtype, which representation type has a pointer-sized | > representation, or | > * an algebraic data type, with one field that has a pointer-sized | > representation. | > | > I'm kinda lost in all the data types that GHC defines to represent | > types. I've gotten no further than | > | > hasPointerSizedRepr :: TyCon -> Bool | > hasPointerSizedRepr tc@(AlgTyCon {}) = case algTcRhs tc of | > DataTyCon{ data_cons = | [data_con] } | > -> ... | > NewTyCon { data_con = | [data_con] } | > -> ... | > _ -> False | > hasPointerSizedRepr _ = False | > | > I could use some pointers (no pun intended!) at this point. The | > function ought to return True for all the following types: | > | > data A = A Int# | > newtype B = B A | > data C = C !B | > data D = D !C | > data E = E !() | > data F = F !D | > | > One part that confuses me is figuring out the representation type of a | > data constructor after unpacking. For example, the function should not | > return true if called on G in this example: | > | > data G = G !H | > data H = H {-# UNPACK #-} !I | > data I = I !Int !Int | > | > because if we unpacked H into G's constructor it would take up two | > words, due to I being unpacked. | > | > Does DataCon contain the unpacked representation of the data | > constructor or only the before-optimizations representation? | | _______________________________________________ | Glasgow-haskell-users mailing list | glasgow-haskell-us...@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
