[ghc-steering-committee] #475: New tuple and list syntax, rec: accept

[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 at 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 <lists at richarde.dev> wrote:
>> 
>> Bump. Could our dear shepherd Vlad guide us toward a conclusion?
>> 
>> Thanks!
>> Richard
>