Between (2) and (3), I'm leaning toward (3). I'm not bothered by the loopiness, and it has the nice properties written in the proposal.

I have also come to lean against (1) at all. Maybe if there's a clamor for it, we can add it later, but I see it as unnecessary. Even if we could make it the primitive definition for tuples (and I bet we could, via data instances), its kind is quite complex and could be a real stumbling block for newcomers and experienced Haskellers alike. For something as fundamental as tuples, I would want to keep the basic definition quite simple.

Richard

> On Mar 1, 2022, at 10:10 AM, Joachim Breitner <mail@joachim-breitner.de> wrote:
>
> Hi,
>
> Am Montag, dem 28.02.2022 um 22:31 +0300 schrieb Vladislav Zavialov
> (int-index):
>> There’s also a new alternative described in the proposal. Here are our options:
>>  1. TupleN A B C
>>  2. Tuple [A, B, C]
>>  3. Tuple (A, B, C)   — NEW
>
> I am not convinced it’s a good idea to introduce many ways of naming
> the same thing, and given that the above three are already in addition
> to the primitive (Tuple2 Bool Int), (which I’ll call (0) below), we
> need a good justification to have more than one.
>
> Between (2) and (3), I’d prefer (3): The strange loop of tuples
> referring to tuples isn’t too unhaskellish, and if it works better for
> unboxed tuples, then yay!
>
> Between (3) and (1) I am unsure. Presumably, if we didn’t have (3) we’d
> use the less idiosyncratic name `Tuple` for (1)?
>
> Are there other, not purely cosmetic, differences between (1) and (3)?
> Maybe related to partial application?
>
>
>
> It’s a bit sad we can't just have (1) without even needing (0), so that
> there really is only _one_ name that’s reasonably ergonomic. How far
> out would that be? Worth making Haskell good enough to support a nice
> design here? :-)
>
> Cheers,
> Joachim
> --
> Joachim Breitner
>  mail@joachim-breitner.de
>  http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee@haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee