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

[Simon Peyton Jones]

> However, I find that Tuple (A, B, C) is weirdly circular, using the tuple
constructor to describe the tuple type

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.

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.

On Mon, 28 Feb 2022 at 19:31, 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
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220301/928ca276/attachment.html>