<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">> 
However, I find that Tuple (A, B, C) is weirdly circular, using the tuple constructor to describe the tuple type <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Is it really so weird?   We still have (A,B,C) for the *data constructor*, right?  So the prefix "Tuple" in the front is a bit like the tick-mark, saying "not the data constructor but the type constructor".   If anything it's stranger to use Tuple to move from list syntax to tuple syntax.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">One might ask (of both): can you write "forall a. Tuple a -> blah", and then instantiate at `[A,B,C]` or `(A,B,C)` resp?  Sorry if the proposal already says this -- but if it doesn't say so explicitly it should, with examples.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 28 Feb 2022 at 19:31, Vladislav Zavialov (int-index) <<a href="mailto:vlad.z.4096@gmail.com">vlad.z.4096@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks for the ping.<br>
<br>
Firstly<br>
=====<br>
<br>
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).<br>
<br>
Secondly<br>
=======<br>
<br>
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.<br>
<br>
There’s also a new alternative described in the proposal. Here are our options:<br>
  1. TupleN A B C<br>
  2. Tuple [A, B, C]<br>
  3. Tuple (A, B, C)   — NEW<br>
<br>
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.<br>
<br>
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`.<br>
<br>
I suggest we stick with Tuple [A, B, C].<br>
<br>
Thirdly<br>
=====<br>
<br>
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. <br>
<br>
Finally<br>
=====<br>
<br>
We still have not heard from Vitaly Bragilevsky, Eric Seidel, Simon Marlow, and Joachim Breitner.<br>
<br>
Let’s wait another week, and then I will assume silence to mean “no objection” and accept the proposal.<br>
<br>
- Vlad<br>
<br>
> On 28 Feb 2022, at 21:38, Richard Eisenberg <<a href="mailto:lists@richarde.dev" target="_blank">lists@richarde.dev</a>> wrote:<br>
> <br>
> Bump. Could our dear shepherd Vlad guide us toward a conclusion?<br>
> <br>
> Thanks!<br>
> Richard<br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>