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

[Spiwack, Arnaud]

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>