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

[Vitaly Bragilevsky]

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 <lists at richarde.dev>:

> 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
> >
>
> _______________________________________________
> 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/212ee63d/attachment-0001.html>