Unpacking sum types

[Richard Eisenberg]

I just added two design notes to the wiki page:
1. If we're stealing syntax, we're stealing quite a few operators. Things like (#|), and (|#) in terms, along with the otherwise-quite-reasonable (x ||). We're also stealing things like (||) and (#||#|) in types. The fact that we're stealing (||) at the type level is quite unfortunate, to me. I won't fight against a growing tide on this issue, but I favor not changing the lexer here and requiring lots of spaces.

2. A previous email in this thread mentioned a (0 of 2 | ...) syntax for data constructors. This might be better than forcing writers and readers to count vertical bars. (Of course, we already require counting commas.)

Glad to see this coming together!
Richard

On Sep 8, 2015, at 7:48 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> |  I see, but then you can't have multiple fields, like
> |  
> |     ( (# Int,Bool #) |)
> |  
> |  You'd have to box the inner tuple too.  Ok, I suppose.
> 
> Well of course!  It's just a parameterised data type, like a tuple.  But, just like unboxed tuples, you could have an unboxed tuple (or sum) inside an unboxed tuple.
> 
>    (# (# Int,Bool #) | Int #)
> 
> Simon
> 
> |  -----Original Message-----
> |  From: Simon Marlow [mailto:marlowsd at gmail.com]
> |  Sent: 08 September 2015 09:55
> |  To: Simon Peyton Jones; Johan Tibell; Ryan Newton
> |  Cc: ghc-devs at haskell.org
> |  Subject: Re: Unpacking sum types
> |  
> |  On 08/09/2015 09:31, Simon Peyton Jones wrote:
> |  > |  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.
> |  
> |  I see, but then you can't have multiple fields, like
> |  
> |     ( (# Int,Bool #) |)
> |  
> |  You'd have to box the inner tuple too.  Ok, I suppose.
> |  
> |  Cheers
> |  Simon
> |  
> |  
> |  > 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
> |  > |  >
> |  >
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs