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

[Tom Harding]

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