I think it took me a while to realise how, despite the fairly pedestrian definition of Tuple2, Tuple3, etc… This proposal is not much different than what exists today (barring the type family shortcuts). There are some weird aspects to the current state of affair: if I write a 77-tuple type, then GHC is quite happy: ```

:k (Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int,Int, Int, Int, Int, Int, Int, Int, Int, Int, Int,Int, Int, Int, Int, Int, Int,Int, Int, Int, Int, Int, Int, Int, Int, Int, Int,Int, Int, Int, Int, Int, Int,Int, Int, Int, Int, Int, Int, Int, Int,Int, Int, Int, Int, Int, Int,Int, Int, Int, Int, Int, Int, Int, Int,Int, Int, Int, Int, Int, Int,Int, Int, Int) (Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int,Int, Int, Int, Int, Int, Int, Int, Int, Int, Int,Int, Int, Int, Int, Int, Int,Int, Int, Int, Int, Int, Int, Int, Int, Int, Int,Int, Int, Int, Int, Int, Int,Int, Int, Int, Int, Int, Int, Int, Int,Int, Int, Int, Int, Int, Int,Int, Int, Int, Int, Int, Int, Int, Int,Int, Int, Int, Int, Int, Int,Int, Int, Int) :: *

But if I do the same with a 77-tuple value, I get an error (a quite
delightful one if I may say so)

:t (True, True, True, True, True, True, True, True, True, True, True, True, True, True,True, True, True, True, True, True, True, True, True, True,True, True, True, True, True, True,True, True, True, True, True, True, True, True, True, True,True, True, True, True, True, True,True, True, True, True, True, True, True, True,True, True, True, True, True, True,True, True, True, True, True, True, True, True,True, True, True, True, True, True,True, True, True)

<interactive>:1:1: error: A 77-tuple is too large for GHC (max size is 62) Workaround: use nested tuples or define a data type ``` With -XNoListTuplePuns, we won't be able to write the former (which is admittedly useless as it doesn't have any values), and would get an unbound type constructor `Tuple77` instead. Or a type error of the latter style in the type family style. I don't think that there is anything wrong with the proposal (though I agree with Vlad and Simon that removing the very clever variadic type family is probably wiser), but I can't help but be worried at the entropy that it introduces. This feature, while cheap, is not free. Is the improvement worth it? I find myself doubting that Haskellers not named Richard or Vlad will start writing `f (Tuple [a, b, c])` in order to avoid writing `f (type (a, b, c))` I'm happy to be convinced. But I'm not yet. On Mon, Jan 31, 2022 at 1:26 PM Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Personally I’d drop TupleN/ConstraintN and accept the rest of the proposal, but I’d love to hear more opinions. Let me know what you think!

I agree.

I'm also not sure if we should have `Tuple` and `Constraints` or `Tuple` and `CTuple`. I lean to the latter.

On Sun, 30 Jan 2022 at 10:24, Vladislav Zavialov (int-index) < vlad.z.4096@gmail.com> wrote:

...

Dear Committee,

Richard has proposed #475 "New tuple and list syntax”. Read it here:

https://github.com/goldfirere/ghc-proposals/blob/tuple-syntax/proposals/0000...

Here’s some background: Earlier we accepted #281 "Visible 'forall' in types of terms”, which introduced, among other things, the -X(No)ListTupleTypeSyntax extension. During implementation, I discovered that this part of the proposal required further design considerations. Richard has kindly agreed to take a stab at this problem, and #475 is the result.

Short summary of the proposal: * Introduce Tuple2, Tuple3, Tuple4, and so on, as alternative ways to write the types of tuples. * Introduce List as the alternative way to write the type of a list. * Do the same for unboxed tuples, unboxed sums, and constraint tuples.

This is the core part of the proposal, for which I strongly urge acceptance.

There are also other minor additions: * Rename -XListTupleTypeSyntax to -XListTuplePuns. * Introduce Tuple [a, b, c] as a more convenient way of writing Tuple3 a b c (likewise for n/=3) * Introduce Constraints [a, b, c] as a more convenient way of writing CTuple3 a b c (likewise for n/=3) * Introduce TupleN a b c as another more convenient way of writing Tuple3 a b c (likewise for n/=3) * Introduce CTupleN a b c as another more convenient way of writing CTuple3 a b c (likewise for n/=3)

I foresee that if we don’t include Tuple/Constraints, users will end up defining their own, with different libraries exporting conflicting definitions. TupleN/ConstraintN, on the other hand, seem weakly motivated.

Personally I’d drop TupleN/ConstraintN and accept the rest of the proposal, but I’d love to hear more opinions. Let me know what you think!

- Vlad _______________________________________________ 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

On Tue, Feb 15, 2022 at 9:49 PM Richard Eisenberg wrote:

I propose we do not worry about 77-tuples. :)

To be clear: I don't worry (nor care) about 77 tuples (plus, for the most part, the change there seems to be for the better). I care about being as clear as possible on the changes that we propose. Hence my exploring the current situation (which is so important that I had no idea what would happen :-) ). But what about `f (Tuple [HList [Int], Bool])`? The alternative, `f (type

(HList [Int], Bool))` has a kind error: HList is expecting a list of types, not a Type. Of course, I could use a ' to get around that kind error, but that's what we're trying to get away from.

Indeed. But is it worth the cost? How about `f (Tuple [HList [Tuple [Int, Bool, Int], Bool])`? The current spelling is `f (type (HList '[(Int, Bool, Int)], Bool)`. Am I more worried about the quote or about the visual noise? It's a genuine question. I'm not convinced either way. /Arnaud

Thanks for the ping. Firstly ===== To answer Arnaud’s question whether the visual noise is worse than the quote – we have earlier agreed on the syntactic unification principle, so the quote has to go (unless we want to start writing it at term level). Secondly ======= Everyone who has expressed their opinion so far (Simon Peyton-Jones, Tom Harding, Arnaud Spiwack, Richard Eisenberg, and I) is either in favor or does not object to dropping TupleN. I suggest to incorporate this change to the proposal now. 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 Why would one write Tuple (A, B, C) rather than Tuple [A, B, C]? This allows us to introduce Tuple# as well: Tuple# [Int#, Double#] does not kind-check, but Tuple# (Int#, Double#) does. However, I find that Tuple (A, B, C) is weirdly circular, using the tuple constructor to describe the tuple type. If, say, Tuple was a data family instead of a type family, this could not possibly work. This leaves me with an uneasy feeling: while I understand how and why it’s an appealing option, it exploits the fact that Tuple is defined on top of the actual tuple types such as Tuple2, Tuple3, Tuple4, etc, whereas I’d like to abstract over this implementation detail. Frankly, it’s hard to choose between (2) and (3). Do we have to choose? Well, this is all about pretty-printing. If we’re fine with printing Tuple3 Int Bool String as is, then we can let libraries define their own type families. But if we want to print it as e.g. Tuple [Int, Bool, String], then the Tuple type family must be hard-coded in the pretty-printer, and therefore provided in `base`. I suggest we stick with Tuple [A, B, C]. Thirdly ===== Since the discussion has started, the proposal evolved a bit and now disallows tuple/list promotion ticks under -XNoListTuplePuns, which I believe is the right call and very much in spirit of the change. Finally ===== We still have not heard from Vitaly Bragilevsky, Eric Seidel, Simon Marlow, and Joachim Breitner. Let’s wait another week, and then I will assume silence to mean “no objection” and accept the proposal. - Vlad

On 28 Feb 2022, at 21:38, Richard Eisenberg wrote:

Bump. Could our dear shepherd Vlad guide us toward a conclusion?

Thanks! Richard

Hi Vlad, I am in favor of dropping TupleN and I'm next to support Tuple [A, B, C] option. And of course, I support the proposal as a whole. Vitaly вт, 1 мар. 2022 г. в 01:36, Richard Eisenberg :

Thanks, Vlad!

I just want to explicitly declare that I am agnostic to the different design choices Vlad mentions below. Whatever we as a committee settle on is fine with me.

Richard

...

On Feb 28, 2022, at 2:31 PM, Vladislav Zavialov (int-index) < vlad.z.4096@gmail.com> wrote:

Thanks for the ping.

Firstly =====

To answer Arnaud’s question whether the visual noise is worse than the quote – we have earlier agreed on the syntactic unification principle, so the quote has to go (unless we want to start writing it at term level).

Secondly =======

Everyone who has expressed their opinion so far (Simon Peyton-Jones, Tom Harding, Arnaud Spiwack, Richard Eisenberg, and I) is either in favor or does not object to dropping TupleN. I suggest to incorporate this change to the proposal now.

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

Why would one write Tuple (A, B, C) rather than Tuple [A, B, C]? This allows us to introduce Tuple# as well: Tuple# [Int#, Double#] does not kind-check, but Tuple# (Int#, Double#) does. However, I find that Tuple (A, B, C) is weirdly circular, using the tuple constructor to describe the tuple type. If, say, Tuple was a data family instead of a type family, this could not possibly work. This leaves me with an uneasy feeling: while I understand how and why it’s an appealing option, it exploits the fact that Tuple is defined on top of the actual tuple types such as Tuple2, Tuple3, Tuple4, etc, whereas I’d like to abstract over this implementation detail.

Frankly, it’s hard to choose between (2) and (3). Do we have to choose? Well, this is all about pretty-printing. If we’re fine with printing Tuple3 Int Bool String as is, then we can let libraries define their own type families. But if we want to print it as e.g. Tuple [Int, Bool, String], then the Tuple type family must be hard-coded in the pretty-printer, and therefore provided in `base`.

I suggest we stick with Tuple [A, B, C].

Thirdly =====

Since the discussion has started, the proposal evolved a bit and now disallows tuple/list promotion ticks under -XNoListTuplePuns, which I believe is the right call and very much in spirit of the change.

Finally =====

We still have not heard from Vitaly Bragilevsky, Eric Seidel, Simon Marlow, and Joachim Breitner.

Let’s wait another week, and then I will assume silence to mean “no objection” and accept the proposal.

- Vlad

...

On 28 Feb 2022, at 21:38, Richard Eisenberg wrote:

Bump. Could our dear shepherd Vlad guide us toward a conclusion?

Thanks! Richard

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

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/

I'm indifferent between (2) and (3). I'm still somewhat unconvinced, though. I understand that this is working towards the Syntax Unification principle. But I don't think that the result pays for itself quite yet. On Tue, Mar 1, 2022 at 8:45 PM Richard Eisenberg wrote:

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 wrote:

Hi,

...

There’s also a new alternative described in the proposal. Here are our

Am Montag, dem 28.02.2022 um 22:31 +0300 schrieb Vladislav Zavialov (int-index): 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

I have done this, and pushed.

On Mar 19, 2022, at 4:22 PM, Vladislav Zavialov (int-index) wrote:

Dear Committee,

it’s time to round up our discussion of #475.

My impression of the discussion is as follows: • Arnaud is skeptical but does not veto. • Tom is in generally favor. • Simon, Richard, and Joachim are in favor and prefer Tuple (A, B, C) over Tuple [A, B, C] • Vitaly and I are in favor and prefer Tuple [A, B, C] over Tuple (A, B, C) • Everyone agrees to drop TupleN.

Thus, the proposal requires the following modifications: 1. Move TupleN, CTupleN, TupleN#, and SumN# to Alternatives. 2. Move Tuple [A, B, C] to Alternatives, and move Tuple (A, B, C) from Alternatives to Proposed Change Specification.

Then we can accept.

Richard, could you do the necessary edits please?

- Vlad

Hi, I think I agree that we could leave out `TupleN`, simply because I’m not sure that there’s a whole lot I could do with these for as long as tuples of different sizes are essentially unrelated types. I’m not entirely sold on the motivation for `Tuple` either; do you/Richard have an example of this family solving a problem? At least as far as I can tell, there’s no way to write functions for a polymorphic list (or number) of types with tuples at the moment - I invariably end up implementing HList. I have a slightly different issue with `Constraints` and `CTupleN`, mostly because I don’t really understand the need for a constraint tuple larger than 2: is it not the case that a constraint tuple `(a, (b, c))` implies `(a, b, c)` and vice versa? I understand that I can distinguish between them using a pattern match, but as I understand it, they evidence exactly the same thing? I’m not sure this is exactly relevant to the proposal, but it would help me understand the motivation. Regardless, these questions are more for my own understanding than any sort of objection to the proposal. I’m in favour, and I think it pairs very well with #270. Thanks, Tom

On 30 Jan 2022, at 10:23, Vladislav Zavialov (int-index) wrote:

Dear Committee,

Richard has proposed #475 "New tuple and list syntax”. Read it here:

https://github.com/goldfirere/ghc-proposals/blob/tuple-syntax/proposals/0000...

Here’s some background: Earlier we accepted #281 "Visible 'forall' in types of terms”, which introduced, among other things, the -X(No)ListTupleTypeSyntax extension. During implementation, I discovered that this part of the proposal required further design considerations. Richard has kindly agreed to take a stab at this problem, and #475 is the result.

Short summary of the proposal: * Introduce Tuple2, Tuple3, Tuple4, and so on, as alternative ways to write the types of tuples. * Introduce List as the alternative way to write the type of a list. * Do the same for unboxed tuples, unboxed sums, and constraint tuples.

This is the core part of the proposal, for which I strongly urge acceptance.

There are also other minor additions: * Rename -XListTupleTypeSyntax to -XListTuplePuns. * Introduce Tuple [a, b, c] as a more convenient way of writing Tuple3 a b c (likewise for n/=3) * Introduce Constraints [a, b, c] as a more convenient way of writing CTuple3 a b c (likewise for n/=3) * Introduce TupleN a b c as another more convenient way of writing Tuple3 a b c (likewise for n/=3) * Introduce CTupleN a b c as another more convenient way of writing CTuple3 a b c (likewise for n/=3)

I foresee that if we don’t include Tuple/Constraints, users will end up defining their own, with different libraries exporting conflicting definitions. TupleN/ConstraintN, on the other hand, seem weakly motivated.

Personally I’d drop TupleN/ConstraintN and accept the rest of the proposal, but I’d love to hear more opinions. Let me know what you think!

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