AnonymousSums data con syntax

[David Kraeutmann]

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
<simonpj at 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-bounces at haskell.org] On Behalf Of Lennart
> Kolmodin
> Sent: 08 September 2015 07:12
> To: Joachim Breitner
> Cc: ghc-devs at haskell.org
> Subject: Re: AnonymousSums data con syntax
>
>
>
>
>
>
>
> 2015-09-07 21:21 GMT+01:00 Joachim Breitner <mail at 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
>   mail at joachim-breitner.de • http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> 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
>