From arnaud.spiwack at tweag.io  Thu Feb 10 16:35:11 2022
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 10 Feb 2022 17:35:11 +0100
Subject: [ghc-steering-committee] #475: New tuple and list syntax,
	rec: accept
In-Reply-To: <CAJKmMz-iC1XL7x7xMRumoEewcMhey-88fY54m2szm+ObM66w8g@mail.gmail.com>
References: <af92c1133ce30ddeff10562f8d73a38d5f4a0a1d.camel@joachim-breitner.de>
 <92A385C3-29EB-4A9B-9EA8-113F9814FEA1@gmail.com>
 <CAJKmMz-iC1XL7x7xMRumoEewcMhey-88fY54m2szm+ObM66w8g@mail.gmail.com>
Message-ID: <CAH6fHQnV5FLk8Ct4zv12b_BmQQPSwge4mo=7aNLr79UQk2g9pw@mail.gmail.com>

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 at 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 at 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-tuple-syntax.rst
>>
>> 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 at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> 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/20220210/8145d8e9/attachment.html>

From mail at joachim-breitner.de  Fri Feb 11 14:01:58 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 11 Feb 2022 15:01:58 +0100
Subject: [ghc-steering-committee] Unimplemented proposals for GSoC
Message-ID: <e384e108bf3cc1a34063b3a7f26b5ace0514fa5a.camel@joachim-breitner.de>

Hallo allerseits,

Gershom suggests that maybe some of the unimplemented accepted GHC
proposals might make good material for a GSoC project.

You can find the (imprecise) list of such proposals at
https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Apr+-label%3A%22Implemented%22++label%3Aaccepted
There are ~50 of them! Surely, a fair number of them _have_ been
implemented and the tag is missing. But still… so maybe this is a good
idea.

Although not every proposal might have the right size and depth for a
GSoC project…

Is there anyone on this commmittee with a bit of experience with GSoC
who might go through the list and highlight possible candidates?

Cheers,
Joachim


-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From i.am.tom.harding at gmail.com  Mon Feb 14 10:18:42 2022
From: i.am.tom.harding at gmail.com (Tom Harding)
Date: Mon, 14 Feb 2022 10:18:42 +0000
Subject: [ghc-steering-committee] #270: Support pun-free code,
 recommendation: accept
In-Reply-To: <CALpVSmPE8waLOVf5NZeRWAqwH-U6EGFTOTKDffB78jAKVvi7GA@mail.gmail.com>
References: <CALpVSmPE8waLOVf5NZeRWAqwH-U6EGFTOTKDffB78jAKVvi7GA@mail.gmail.com>
Message-ID: <D60D9983-3689-4FBB-BFE0-F65094B93BDD@gmail.com>

Whew! Finally caught up with the PR discussion.

I agree with Simon: I don’t think adding style warnings is too dramatic a change, and my experience of introducing people to Haskell has involved a lot of confusion around punning, so I think discouraging punning is probably a good idea.

I do also like the import syntax, though, as an idealist, I am hoping that it can eventually be deprecated (once enough code is free of bad puns). Until then, I think this is a nice extra bit of clarity. As someone who habitually decorates everything with explicit forall, standalone kind signatures, explicit deriving strategies, and so on… well, I’m always a fan of extra clarity :-)

In short: I like this, and I’m in favour of acceptance.

Cheers,
Tom

> On 29 Jan 2022, at 15:41, Vitaly Bragilevsky <bravit111 at gmail.com> wrote:
> 
> Dear Committee,
> 
> Proposal #270 "Support pun-free code" has been resubmitted by Artyom Kuznetsov.
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/270
> 
> https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md
> 
> This proposal was heavily revised since Iavor recommended rejection.
> As of now, it is quite thin suggesting just a couple of things:
> - warnings for the code with panning (understood as using same names
> for both types and values)
> - a syntax change for import declarations to reflect which names
> (types or values) are actually imported when importing from libraries
> relied on punning.
> 
> The first change promotes a new style of writing Haskell code without
> distinguishing types and values and having a single unified namespace.
> We are already on that road anyway and I don't see any reason not to
> support this.
> 
> The second change allows using an old style with punning. It could
> lead to doubling import declarations, but I don't think that this is
> really a problem.
> 
> I think the proposal is mature enough so I recommend acceptance.
> 
> We can also decide on the actual word used in import declarations
> (data, value, or pattern). I personally prefer value, but I don't see
> this issue as something important.
> 
> Vitaly
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From i.am.tom.harding at gmail.com  Mon Feb 14 10:48:50 2022
From: i.am.tom.harding at gmail.com (Tom Harding)
Date: Mon, 14 Feb 2022 10:48:50 +0000
Subject: [ghc-steering-committee] #475: New tuple and list syntax,
 rec: accept
In-Reply-To: <92A385C3-29EB-4A9B-9EA8-113F9814FEA1@gmail.com>
References: <af92c1133ce30ddeff10562f8d73a38d5f4a0a1d.camel@joachim-breitner.de>
 <92A385C3-29EB-4A9B-9EA8-113F9814FEA1@gmail.com>
Message-ID: <31D50336-7067-4645-ACC0-E539C996046E@gmail.com>

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) <vlad.z.4096 at 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-tuple-syntax.rst
> 
> 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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From mail at joachim-breitner.de  Tue Feb 15 11:27:58 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 15 Feb 2022 12:27:58 +0100
Subject: [ghc-steering-committee]  #477: Unicode ellipsis,
 recommendation: accept
Message-ID: <e3eb9fe01341dbab0f5fd2c1c49050feb3d26bb2.camel@joachim-breitner.de>

Dear Committee,

Proposal #277 “Unicode ellipsis” has been submitted by Ignat Insarov,
and I’m shepherding it myself.

https://github.com/ghc-proposals/ghc-proposals/pull/477

https://github.com/kindaro/ghc-proposals/blob/unicode-ellipsis/proposals/477-unicode-ellipsis.md

This is a very small proposal that lets GHC understand the nice Unicode
syntax `…` in places where in ASCII world we have .., under
-XUnicodeSyntax.

I am fond of Unicode in general, and I expect that users of -
XUnicodeSyntax expect this to work, and therefore recommend acceptance
of this proposal.

Cheers,
Joachim



-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From arnaud.spiwack at tweag.io  Tue Feb 15 14:33:06 2022
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Tue, 15 Feb 2022 15:33:06 +0100
Subject: [ghc-steering-committee] #477: Unicode ellipsis,
	recommendation: accept
In-Reply-To: <e3eb9fe01341dbab0f5fd2c1c49050feb3d26bb2.camel@joachim-breitner.de>
References: <e3eb9fe01341dbab0f5fd2c1c49050feb3d26bb2.camel@joachim-breitner.de>
Message-ID: <CAH6fHQkEJ5rcBoQRL+JORCUVE6BW6gcq_rrRup7R3RB_njy7kw@mail.gmail.com>

It's fine with me too (I'm fond of unicode as well, and never use it…). I
just have a question: is there a reason why the ascii syntax is `..` and
not `...`?

On Tue, Feb 15, 2022 at 12:28 PM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> Proposal #277 “Unicode ellipsis” has been submitted by Ignat Insarov,
> and I’m shepherding it myself.
>
> https://github.com/ghc-proposals/ghc-proposals/pull/477
>
>
> https://github.com/kindaro/ghc-proposals/blob/unicode-ellipsis/proposals/477-unicode-ellipsis.md
>
> This is a very small proposal that lets GHC understand the nice Unicode
> syntax `…` in places where in ASCII world we have .., under
> -XUnicodeSyntax.
>
> I am fond of Unicode in general, and I expect that users of -
> XUnicodeSyntax expect this to work, and therefore recommend acceptance
> of this proposal.
>
> Cheers,
> Joachim
>
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> 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/20220215/670a502c/attachment.html>

From lists at richarde.dev  Tue Feb 15 19:02:22 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Tue, 15 Feb 2022 19:02:22 +0000
Subject: [ghc-steering-committee] #477: Unicode ellipsis,
 recommendation: accept
In-Reply-To: <e3eb9fe01341dbab0f5fd2c1c49050feb3d26bb2.camel@joachim-breitner.de>
References: <e3eb9fe01341dbab0f5fd2c1c49050feb3d26bb2.camel@joachim-breitner.de>
Message-ID: <010f017efec3a83f-bfdb9fae-f29f-40e9-b3a7-f1b3aa93f861-000000@us-east-2.amazonses.com>

I support this, though I note that it is just barely possible that this proposal will break code in the wild. Packages control-dotdotdot and ghc-justdoit both define a (…) operator. I don't easily see whether they enable -XUnicodeSyntax, though.

Still: +1

Richard

> On Feb 15, 2022, at 6:27 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Dear Committee,
> 
> Proposal #277 “Unicode ellipsis” has been submitted by Ignat Insarov,
> and I’m shepherding it myself.
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/477
> 
> https://github.com/kindaro/ghc-proposals/blob/unicode-ellipsis/proposals/477-unicode-ellipsis.md
> 
> This is a very small proposal that lets GHC understand the nice Unicode
> syntax `…` in places where in ASCII world we have .., under
> -XUnicodeSyntax.
> 
> I am fond of Unicode in general, and I expect that users of -
> XUnicodeSyntax expect this to work, and therefore recommend acceptance
> of this proposal.
> 
> Cheers,
> Joachim
> 
> 
> 
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From vlad.z.4096 at gmail.com  Tue Feb 15 19:37:24 2022
From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index))
Date: Tue, 15 Feb 2022 22:37:24 +0300
Subject: [ghc-steering-committee] #477: Unicode ellipsis,
 recommendation: accept
In-Reply-To: <e3eb9fe01341dbab0f5fd2c1c49050feb3d26bb2.camel@joachim-breitner.de>
References: <e3eb9fe01341dbab0f5fd2c1c49050feb3d26bb2.camel@joachim-breitner.de>
Message-ID: <18DD3012-398A-4FA9-8881-D1C04B9BE2DE@gmail.com>

-1 from me.

The proposed (… U+2026) is three dots, so it could be the UnicodeSyntax equivalent to three ASCII dots. However, Haskell’s range notation is two ASCII dots.

Personally I use three dots to indicate omissions in the source text, like this:

  f x = …

So that is the meaning I’d like to reserve for three dots, not ranges.

The proposal could use ‥ U+2025 instead.

- Vlad


> On 15 Feb 2022, at 14:27, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Dear Committee,
> 
> Proposal #277 “Unicode ellipsis” has been submitted by Ignat Insarov,
> and I’m shepherding it myself.
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/477
> 
> https://github.com/kindaro/ghc-proposals/blob/unicode-ellipsis/proposals/477-unicode-ellipsis.md
> 
> This is a very small proposal that lets GHC understand the nice Unicode
> syntax `…` in places where in ASCII world we have .., under
> -XUnicodeSyntax.
> 
> I am fond of Unicode in general, and I expect that users of -
> XUnicodeSyntax expect this to work, and therefore recommend acceptance
> of this proposal.
> 
> Cheers,
> Joachim
> 
> 
> 
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From lists at richarde.dev  Tue Feb 15 20:49:23 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Tue, 15 Feb 2022 20:49:23 +0000
Subject: [ghc-steering-committee] #475: New tuple and list syntax,
 rec: accept
In-Reply-To: <CAH6fHQnV5FLk8Ct4zv12b_BmQQPSwge4mo=7aNLr79UQk2g9pw@mail.gmail.com>
References: <af92c1133ce30ddeff10562f8d73a38d5f4a0a1d.camel@joachim-breitner.de>
 <92A385C3-29EB-4A9B-9EA8-113F9814FEA1@gmail.com>
 <CAJKmMz-iC1XL7x7xMRumoEewcMhey-88fY54m2szm+ObM66w8g@mail.gmail.com>
 <CAH6fHQnV5FLk8Ct4zv12b_BmQQPSwge4mo=7aNLr79UQk2g9pw@mail.gmail.com>
Message-ID: <010f017eff25a113-34a9d84d-399d-4252-a938-cbea1283cc96-000000@us-east-2.amazonses.com>

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

> On Feb 10, 2022, at 11:35 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 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))`

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.

Richard

> 
> 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 at gmail.com <mailto:simon.peytonjones at 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 at gmail.com <mailto:vlad.z.4096 at 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-tuple-syntax.rst <https://github.com/goldfirere/ghc-proposals/blob/tuple-syntax/proposals/0000-tuple-syntax.rst>
> 
> 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 at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> 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/20220215/c86296e4/attachment-0001.html>

From lists at richarde.dev  Tue Feb 15 20:54:04 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Tue, 15 Feb 2022 20:54:04 +0000
Subject: [ghc-steering-committee] #475: New tuple and list syntax,
 rec: accept
In-Reply-To: <31D50336-7067-4645-ACC0-E539C996046E@gmail.com>
References: <af92c1133ce30ddeff10562f8d73a38d5f4a0a1d.camel@joachim-breitner.de>
 <92A385C3-29EB-4A9B-9EA8-113F9814FEA1@gmail.com>
 <31D50336-7067-4645-ACC0-E539C996046E@gmail.com>
Message-ID: <010f017eff29ed79-b45c42a4-e6dd-400e-bff3-eca8d7dc96dc-000000@us-east-2.amazonses.com>

I'm fine with dropping TupleN. It's something that I thought people would want, but I don't have to supply it -- any library could define TupleN. (To be clear, there's no new expressiveness in TupleN that we don't have without it. It's just for convenience.)

> On Feb 14, 2022, at 5:48 AM, Tom Harding <i.am.tom.harding at gmail.com> wrote:
> 
> 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.

You are right that (a, (b, c)) implies (a, b, c) and vice versa. But there are at least two differences between them:

- Representation. When you write a function `(Show a, (Eq a, Num a)) => a -> a`, GHC produces a function that takes three arguments at runtime: a Show a dictionary, a pair of dictionaries for (Eq a, Num a), and an argument of type a. (As stated in the proposal, the top-level (...) => syntax is special.) So (Show a, Eq a, Num a) => ... is more efficient at runtime than (Show a, (Eq a, Num a)) => ...

- Type equality. As you suggest, we can differentiate between the two sets of constraint by pattern matching. For example, `Dict (Show a, (Eq a, Num a))` is not equal to `Dict (Show a, Eq a, Num a)`. 

I hope this helps!
Richard

From arnaud.spiwack at tweag.io  Wed Feb 16 08:38:08 2022
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Wed, 16 Feb 2022 09:38:08 +0100
Subject: [ghc-steering-committee] #475: New tuple and list syntax,
	rec: accept
In-Reply-To: <010f017eff25a113-34a9d84d-399d-4252-a938-cbea1283cc96-000000@us-east-2.amazonses.com>
References: <af92c1133ce30ddeff10562f8d73a38d5f4a0a1d.camel@joachim-breitner.de>
 <92A385C3-29EB-4A9B-9EA8-113F9814FEA1@gmail.com>
 <CAJKmMz-iC1XL7x7xMRumoEewcMhey-88fY54m2szm+ObM66w8g@mail.gmail.com>
 <CAH6fHQnV5FLk8Ct4zv12b_BmQQPSwge4mo=7aNLr79UQk2g9pw@mail.gmail.com>
 <010f017eff25a113-34a9d84d-399d-4252-a938-cbea1283cc96-000000@us-east-2.amazonses.com>
Message-ID: <CAH6fHQk1wJnU5128XECG0BOVmmtJRE_2CQgVHK7XYZTJsWMiVA@mail.gmail.com>

On Tue, Feb 15, 2022 at 9:49 PM Richard Eisenberg <lists at richarde.dev>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220216/1c30dd88/attachment.html>

From simon.peytonjones at gmail.com  Wed Feb 23 16:59:14 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 23 Feb 2022 16:59:14 +0000
Subject: [ghc-steering-committee] #477: Unicode ellipsis,
	recommendation: accept
In-Reply-To: <e3eb9fe01341dbab0f5fd2c1c49050feb3d26bb2.camel@joachim-breitner.de>
References: <e3eb9fe01341dbab0f5fd2c1c49050feb3d26bb2.camel@joachim-breitner.de>
Message-ID: <CAJKmMz_w4939MYCRtHDqcxEAL05g-uV5ypiwChE_w2X=AMq-Hg@mail.gmail.com>

Fine with me.

Simon

On Tue, 15 Feb 2022 at 11:28, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> Proposal #277 “Unicode ellipsis” has been submitted by Ignat Insarov,
> and I’m shepherding it myself.
>
> https://github.com/ghc-proposals/ghc-proposals/pull/477
>
>
> https://github.com/kindaro/ghc-proposals/blob/unicode-ellipsis/proposals/477-unicode-ellipsis.md
>
> This is a very small proposal that lets GHC understand the nice Unicode
> syntax `…` in places where in ASCII world we have .., under
> -XUnicodeSyntax.
>
> I am fond of Unicode in general, and I expect that users of -
> XUnicodeSyntax expect this to work, and therefore recommend acceptance
> of this proposal.
>
> Cheers,
> Joachim
>
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> 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/20220223/411b9d05/attachment.html>

From eric at seidel.io  Fri Feb 25 01:48:30 2022
From: eric at seidel.io (Eric Seidel)
Date: Thu, 24 Feb 2022 20:48:30 -0500
Subject: [ghc-steering-committee] #477: Unicode ellipsis,
	recommendation: accept
In-Reply-To: <18DD3012-398A-4FA9-8881-D1C04B9BE2DE@gmail.com>
References: <e3eb9fe01341dbab0f5fd2c1c49050feb3d26bb2.camel@joachim-breitner.de>
 <18DD3012-398A-4FA9-8881-D1C04B9BE2DE@gmail.com>
Message-ID: <9a059656-128d-4282-a156-161d0eb4c00d@www.fastmail.com>

I agree it's strange to use a three dot unicode ellipsis but a two dot ascii ellipsis. 

Joachim, as someone who likes to use unicode in Haskell, is there a reason to think that the two dot ellipsis would be more cumbersome to type? Maybe emacs unicode modes or something?

On Tue, Feb 15, 2022, at 14:37, Vladislav Zavialov (int-index) wrote:
> -1 from me.
>
> The proposed (… U+2026) is three dots, so it could be the UnicodeSyntax 
> equivalent to three ASCII dots. However, Haskell’s range notation is 
> two ASCII dots.
>
> Personally I use three dots to indicate omissions in the source text, like this:
>
>   f x = …
>
> So that is the meaning I’d like to reserve for three dots, not ranges.
>
> The proposal could use ‥ U+2025 instead.
>
> - Vlad
>
>
>> On 15 Feb 2022, at 14:27, Joachim Breitner <mail at joachim-breitner.de> wrote:
>> 
>> Dear Committee,
>> 
>> Proposal #277 “Unicode ellipsis” has been submitted by Ignat Insarov,
>> and I’m shepherding it myself.
>> 
>> https://github.com/ghc-proposals/ghc-proposals/pull/477
>> 
>> https://github.com/kindaro/ghc-proposals/blob/unicode-ellipsis/proposals/477-unicode-ellipsis.md
>> 
>> This is a very small proposal that lets GHC understand the nice Unicode
>> syntax `…` in places where in ASCII world we have .., under
>> -XUnicodeSyntax.
>> 
>> I am fond of Unicode in general, and I expect that users of -
>> XUnicodeSyntax expect this to work, and therefore recommend acceptance
>> of this proposal.
>> 
>> Cheers,
>> Joachim
>> 
>> 
>> 
>> -- 
>> Joachim Breitner
>>  mail at joachim-breitner.de
>>  http://www.joachim-breitner.de/
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From arnaud.spiwack at tweag.io  Fri Feb 25 07:44:10 2022
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 25 Feb 2022 08:44:10 +0100
Subject: [ghc-steering-committee] #477: Unicode ellipsis,
	recommendation: accept
In-Reply-To: <9a059656-128d-4282-a156-161d0eb4c00d@www.fastmail.com>
References: <e3eb9fe01341dbab0f5fd2c1c49050feb3d26bb2.camel@joachim-breitner.de>
 <18DD3012-398A-4FA9-8881-D1C04B9BE2DE@gmail.com>
 <9a059656-128d-4282-a156-161d0eb4c00d@www.fastmail.com>
Message-ID: <CAH6fHQkam7VEGDGnoebBeRuA+PxrAChUTvC60eqqOhAOSkEbyA@mail.gmail.com>

Eric,

If you use a compose key on Linux, chances are that ellipsis is bound to
`compose-.-.`. I don't think the two-point ellipsis is typically bound to
anything.
On Emacs, input methods are easily extensible, but if you use Company Math
to write unicode symbols (which is an autocompletion-based approach), which
I've never figured out how to configure, then you will have ellipsis bound
on `\ldots`, but no two-point ellipsis.

If someone has insight about why the syntax was chosen to be two dots
rather than three, originally. I still think that it could inform this
discussion.

On Fri, Feb 25, 2022 at 2:49 AM Eric Seidel <eric at seidel.io> wrote:

> I agree it's strange to use a three dot unicode ellipsis but a two dot
> ascii ellipsis.
>
> Joachim, as someone who likes to use unicode in Haskell, is there a reason
> to think that the two dot ellipsis would be more cumbersome to type? Maybe
> emacs unicode modes or something?
>
> On Tue, Feb 15, 2022, at 14:37, Vladislav Zavialov (int-index) wrote:
> > -1 from me.
> >
> > The proposed (… U+2026) is three dots, so it could be the UnicodeSyntax
> > equivalent to three ASCII dots. However, Haskell’s range notation is
> > two ASCII dots.
> >
> > Personally I use three dots to indicate omissions in the source text,
> like this:
> >
> >   f x = …
> >
> > So that is the meaning I’d like to reserve for three dots, not ranges.
> >
> > The proposal could use ‥ U+2025 instead.
> >
> > - Vlad
> >
> >
> >> On 15 Feb 2022, at 14:27, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
> >>
> >> Dear Committee,
> >>
> >> Proposal #277 “Unicode ellipsis” has been submitted by Ignat Insarov,
> >> and I’m shepherding it myself.
> >>
> >> https://github.com/ghc-proposals/ghc-proposals/pull/477
> >>
> >>
> https://github.com/kindaro/ghc-proposals/blob/unicode-ellipsis/proposals/477-unicode-ellipsis.md
> >>
> >> This is a very small proposal that lets GHC understand the nice Unicode
> >> syntax `…` in places where in ASCII world we have .., under
> >> -XUnicodeSyntax.
> >>
> >> I am fond of Unicode in general, and I expect that users of -
> >> XUnicodeSyntax expect this to work, and therefore recommend acceptance
> >> of this proposal.
> >>
> >> Cheers,
> >> Joachim
> >>
> >>
> >>
> >> --
> >> Joachim Breitner
> >>  mail at joachim-breitner.de
> >>  http://www.joachim-breitner.de/
> >>
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> 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/20220225/f6b23df5/attachment.html>

From lists at richarde.dev  Mon Feb 28 18:38:45 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Mon, 28 Feb 2022 18:38:45 +0000
Subject: [ghc-steering-committee] #475: New tuple and list syntax,
 rec: accept
In-Reply-To: <CAH6fHQk1wJnU5128XECG0BOVmmtJRE_2CQgVHK7XYZTJsWMiVA@mail.gmail.com>
References: <af92c1133ce30ddeff10562f8d73a38d5f4a0a1d.camel@joachim-breitner.de>
 <92A385C3-29EB-4A9B-9EA8-113F9814FEA1@gmail.com>
 <CAJKmMz-iC1XL7x7xMRumoEewcMhey-88fY54m2szm+ObM66w8g@mail.gmail.com>
 <CAH6fHQnV5FLk8Ct4zv12b_BmQQPSwge4mo=7aNLr79UQk2g9pw@mail.gmail.com>
 <010f017eff25a113-34a9d84d-399d-4252-a938-cbea1283cc96-000000@us-east-2.amazonses.com>
 <CAH6fHQk1wJnU5128XECG0BOVmmtJRE_2CQgVHK7XYZTJsWMiVA@mail.gmail.com>
Message-ID: <010f017f41a0b450-f6350d30-4226-4ca9-a9c4-8f969ea020a3-000000@us-east-2.amazonses.com>

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

Thanks!
Richard

> On Feb 16, 2022, at 3:38 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> On Tue, Feb 15, 2022 at 9:49 PM Richard Eisenberg <lists at richarde.dev <mailto:lists at richarde.dev>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220228/4ceb346d/attachment.html>

From vlad.z.4096 at gmail.com  Mon Feb 28 19:31:30 2022
From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index))
Date: Mon, 28 Feb 2022 22:31:30 +0300
Subject: [ghc-steering-committee] #475: New tuple and list syntax,
 rec: accept
In-Reply-To: <010f017f41a0b450-f6350d30-4226-4ca9-a9c4-8f969ea020a3-000000@us-east-2.amazonses.com>
References: <af92c1133ce30ddeff10562f8d73a38d5f4a0a1d.camel@joachim-breitner.de>
 <92A385C3-29EB-4A9B-9EA8-113F9814FEA1@gmail.com>
 <CAJKmMz-iC1XL7x7xMRumoEewcMhey-88fY54m2szm+ObM66w8g@mail.gmail.com>
 <CAH6fHQnV5FLk8Ct4zv12b_BmQQPSwge4mo=7aNLr79UQk2g9pw@mail.gmail.com>
 <010f017eff25a113-34a9d84d-399d-4252-a938-cbea1283cc96-000000@us-east-2.amazonses.com>
 <CAH6fHQk1wJnU5128XECG0BOVmmtJRE_2CQgVHK7XYZTJsWMiVA@mail.gmail.com>
 <010f017f41a0b450-f6350d30-4226-4ca9-a9c4-8f969ea020a3-000000@us-east-2.amazonses.com>
Message-ID: <A8A0D32C-A033-49BA-BB0E-D5FE412695EB@gmail.com>

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


From lists at richarde.dev  Mon Feb 28 22:36:34 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Mon, 28 Feb 2022 22:36:34 +0000
Subject: [ghc-steering-committee] #475: New tuple and list syntax,
 rec: accept
In-Reply-To: <A8A0D32C-A033-49BA-BB0E-D5FE412695EB@gmail.com>
References: <af92c1133ce30ddeff10562f8d73a38d5f4a0a1d.camel@joachim-breitner.de>
 <92A385C3-29EB-4A9B-9EA8-113F9814FEA1@gmail.com>
 <CAJKmMz-iC1XL7x7xMRumoEewcMhey-88fY54m2szm+ObM66w8g@mail.gmail.com>
 <CAH6fHQnV5FLk8Ct4zv12b_BmQQPSwge4mo=7aNLr79UQk2g9pw@mail.gmail.com>
 <010f017eff25a113-34a9d84d-399d-4252-a938-cbea1283cc96-000000@us-east-2.amazonses.com>
 <CAH6fHQk1wJnU5128XECG0BOVmmtJRE_2CQgVHK7XYZTJsWMiVA@mail.gmail.com>
 <010f017f41a0b450-f6350d30-4226-4ca9-a9c4-8f969ea020a3-000000@us-east-2.amazonses.com>
 <A8A0D32C-A033-49BA-BB0E-D5FE412695EB@gmail.com>
Message-ID: <010f017f427a6eae-ee69e2bd-5771-4bab-9b4b-1e94691ee67e-000000@us-east-2.amazonses.com>

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
>