<div dir="ltr"><div>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:</div><div><br></div><div>```</div><div>> :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)<br>(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) :: *</div><div>```</div><div><br></div><div>But if I do the same with a 77-tuple value, I get an error (a quite delightful one if I may say so)</div><div><br></div><div>```</div><div>> :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)<br><br><interactive>:1:1: error:<br> A 77-tuple is too large for GHC<br> (max size is 62)<br> Workaround: use nested tuples or define a data type</div><div>```</div><div><br></div><div>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.</div><div><br></div><div>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))`</div><div><br></div><div>I'm happy to be convinced. But I'm not yet.<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 31, 2022 at 1:26 PM Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com">simon.peytonjones@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"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">>
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! <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I agree. <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I'm also not sure if we should have `Tuple` and `Constraints` or `Tuple` and `CTuple`. I lean to the latter.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 30 Jan 2022 at 10:24, Vladislav Zavialov (int-index) <<a href="mailto:vlad.z.4096@gmail.com" target="_blank">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">Dear Committee,<br>
<br>
Richard has proposed #475 "New tuple and list syntax”. Read it here:<br>
<br>
<a href="https://github.com/goldfirere/ghc-proposals/blob/tuple-syntax/proposals/0000-tuple-syntax.rst" rel="noreferrer" target="_blank">https://github.com/goldfirere/ghc-proposals/blob/tuple-syntax/proposals/0000-tuple-syntax.rst</a><br>
<br>
Here’s some background:<br>
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.<br>
<br>
Short summary of the proposal:<br>
* Introduce Tuple2, Tuple3, Tuple4, and so on, as alternative ways to write the types of tuples.<br>
* Introduce List as the alternative way to write the type of a list.<br>
* Do the same for unboxed tuples, unboxed sums, and constraint tuples.<br>
<br>
This is the core part of the proposal, for which I strongly urge acceptance.<br>
<br>
There are also other minor additions:<br>
* Rename -XListTupleTypeSyntax to -XListTuplePuns.<br>
* Introduce Tuple [a, b, c] as a more convenient way of writing Tuple3 a b c (likewise for n/=3)<br>
* Introduce Constraints [a, b, c] as a more convenient way of writing CTuple3 a b c (likewise for n/=3)<br>
* Introduce TupleN a b c as another more convenient way of writing Tuple3 a b c (likewise for n/=3)<br>
* Introduce CTupleN a b c as another more convenient way of writing CTuple3 a b c (likewise for n/=3)<br>
<br>
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.<br>
<br>
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!<br>
<br>
- Vlad<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>
_______________________________________________<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>