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@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...
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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee