Unpacking sum types

[Dan Doel]

I don't think any #-based operators are stolen at the term level,
because # is required at both ends.

`(#| x #)` is not a legal operator section (nor is `(#| x |#)`), and
(#|_#) is not an operator name. The boxed version only steals
operators because you can shove the entire thing to one side.

I might have missed something, though.

The type level steals type operators involving #, though.

On Tue, Sep 8, 2015 at 8:05 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> 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
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs