Unpacking sum types
Simon Peyton Jones
simonpj at microsoft.com
Tue Sep 8 08:31:45 UTC 2015
| How did you envisage implementing anonymous boxed sums? What is their
| heap representation?
*Exactly* like tuples; that is, we have a family of data type declarations:
data (a|b) = (_|) a
| (|_) b
data (a|b|c) = (_||) a
| (|_|) b
| (||_) c
| One option is to use some kind of generic object with a dynamic number
| of pointers and non-pointers, and one field for the tag. The layout
| would need to be stored in the object. This isn't a particularly
| efficient representation, though. Perhaps there could be a family of
| smaller specialised versions for common sizes.
| Do we have a use case for the boxed version, or is it just for
| > Looks good to me!
| > Simon
| > *From:*Johan Tibell [mailto:johan.tibell at gmail.com]
| > *Sent:* 01 September 2015 18:24
| > *To:* Simon Peyton Jones; Simon Marlow; Ryan Newton
| > *Cc:* ghc-devs at haskell.org
| > *Subject:* RFC: Unpacking sum types
| > I have a draft design for unpacking sum types that I'd like some
| > feedback on. In particular feedback both on:
| > * the writing and clarity of the proposal and
| > * the proposal itself.
| > https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes
| > -- Johan
More information about the ghc-devs