Unpacking sum types

[Simon Peyton Jones]

|  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
..etc.

Simon

|  
|  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
|  consistency?
|  
|  Cheers
|  Simon
|  
|  
|  > 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
|  >