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 <e...@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 <simo...@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:marlo...@gmail.com] >> | Sent: 08 September 2015 09:55 >> | To: Simon Peyton Jones; Johan Tibell; Ryan Newton >> | Cc: ghc-devs@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.tib...@gmail.com] > *Sent:* >> | 01 >> | > | September 2015 18:24 > *To:* Simon Peyton Jones; Simon Marlow; >> | Ryan >> | > | Newton > *Cc:* ghc-devs@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@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs