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

[Richard Eisenberg]

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>