For what's it worth, I feel like (|True|||) looks better than (2/5|True) or (2 of 5|True). Not sure if the confusion w/r/t (x||) as or section or 3-ary anonymous sum is worth it though.
On Tue, Sep 8, 2015 at 10:28 AM, Simon Peyton Jones <simo...@microsoft.com> wrote: > I can see the force of this discussion about data type constructors for > sums, but > > · We already do this for tuples: (,,,,) is a type constructor and > you have to count commas. We could use a number here but we don’t. > > · Likewise tuple sections. (,,e,) means (\xyz. (x,y,e,z)) > > I do not expect big sums in practice. > > > > That said, (2/5| True) instead of (|True|||) would be ok I suppose. Or > something like that. > > > > Simon > > > > From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Lennart > Kolmodin > Sent: 08 September 2015 07:12 > To: Joachim Breitner > Cc: ghc-devs@haskell.org > Subject: Re: AnonymousSums data con syntax > > > > > > > > 2015-09-07 21:21 GMT+01:00 Joachim Breitner <m...@joachim-breitner.de>: > > Hi, > > Am Montag, den 07.09.2015, 19:25 +0000 schrieb Simon Peyton Jones: >> > Are we okay with stealing some operator sections for this? E.G. (x >> > > > ). I think the boxed sums larger than 2 choices are all technically >> > > > overlapping with sections. >> >> I hadn't thought of that. I suppose that in distfix notation we >> could require spaces >> (x | |) >> since vertical bar by itself isn't an operator. But then (_||) x >> might feel more compact. >> >> Also a section (x ||) isn't valid in a pattern, so we would not need >> to require spaces there. >> >> But my gut feel is: yes, with AnonymousSums we should just steal the >> syntax. It won't hurt existing code (since it won't use >> AnonymousSums), and if you *are* using AnonymousSums then the distfix >> notation is probably more valuable than the sections for an operator >> you probably aren't using. > > I wonder if this syntax for constructors is really that great. Yes, you > there is similarly with the type constructor (which is nice), but for > the data constructor, do we really want an unary encoding and have our > users count bars? > > I believe the user (and also us, having to read core) would be better > served by some syntax that involves plain numbers. > > > > I reacted the same way to the proposed syntax. > > Imagine already having an anonymous sum type and then deciding adding > another constructor. Naturally you'd have to update your code to handle the > new constructor, but you also need to update the code for all other > constructors as well by adding another bar in the right place. That seems > unnecessary and there's no need to do that for named sum types. > > > > What about explicitly stating the index as a number? > > > > (1 | Int) :: ( String | Int | Bool ) > > (#1 | Int #) :: (# String | Int | Bool #) > > > > case sum of > > (0 | myString ) -> ... > > (1 | myInt ) -> ... > > (2 | myBool ) -> ... > > > > This allows you to at least add new constructors at the end without changing > existing code. > > Is it harder to resolve by type inference since we're not stating the number > of constructors? If so we could do something similar to Joachim's proposal; > > > > case sum of > > (0 of 3 | myString ) -> ... > > (1 of 3 | myInt ) -> ... > > (2 of 3 | myBool ) -> ... > > > > .. and at least you don't have to count bars. > > > > > Given that of is already a keyword, how about something involving "3 > of 4"? For example > > (Put# True in 3 of 5) :: (# a | b | Bool | d | e #) > > and > > case sum of > (Put# x in 1 of 3) -> ... > (Put# x in 2 of 3) -> ... > (Put# x in 3 of 3) -> ... > > (If "as" were a keyword, (Put# x as 2 of 3) would sound even better.) > > > I don’t find this particular choice very great, but something with > numbers rather than ASCII art seems to make more sense here. Is there > something even better? > > Greetings, > Joachim > > > > > -- > Joachim “nomeata” Breitner > m...@joachim-breitner.de • http://www.joachim-breitner.de/ > Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F > Debian Developer: nome...@debian.org > > _______________________________________________ > 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