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

[Spiwack, Arnaud]

I'm indifferent between (2) and (3). I'm still somewhat unconvinced,
though. I understand that this is working towards the Syntax Unification
principle. But I don't think that the result pays for itself quite yet.

On Tue, Mar 1, 2022 at 8:45 PM Richard Eisenberg <lists at richarde.dev> wrote:

> Between (2) and (3), I'm leaning toward (3). I'm not bothered by the
> loopiness, and it has the nice properties written in the proposal.
>
> I have also come to lean against (1) at all. Maybe if there's a clamor for
> it, we can add it later, but I see it as unnecessary. Even if we could make
> it the primitive definition for tuples (and I bet we could, via data
> instances), its kind is quite complex and could be a real stumbling block
> for newcomers and experienced Haskellers alike. For something as
> fundamental as tuples, I would want to keep the basic definition quite
> simple.
>
> Richard
>
> > On Mar 1, 2022, at 10:10 AM, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
> >
> > Hi,
> >
> > Am Montag, dem 28.02.2022 um 22:31 +0300 schrieb Vladislav Zavialov
> > (int-index):
> >> There’s also a new alternative described in the proposal. Here are our
> options:
> >>  1. TupleN A B C
> >>  2. Tuple [A, B, C]
> >>  3. Tuple (A, B, C)   — NEW
> >
> > I am not convinced it’s a good idea to introduce many ways of naming
> > the same thing, and given that the above three are already in addition
> > to the primitive (Tuple2 Bool Int), (which I’ll call (0) below), we
> > need a good justification to have more than one.
> >
> > Between (2) and (3), I’d prefer (3): The strange loop of tuples
> > referring to tuples isn’t too unhaskellish, and if it works better for
> > unboxed tuples, then yay!
> >
> > Between (3) and (1) I am unsure. Presumably, if we didn’t have (3) we’d
> > use the less idiosyncratic name `Tuple` for (1)?
> >
> > Are there other, not purely cosmetic, differences between (1) and (3)?
> > Maybe related to partial application?
> >
> >
> >
> > It’s a bit sad we can't just have (1) without even needing (0), so that
> > there really is only _one_ name that’s reasonably ergonomic. How far
> > out would that be? Worth making Haskell good enough to support a nice
> > design here? :-)
> >
> > Cheers,
> > Joachim
> > --
> > Joachim Breitner
> >  mail at joachim-breitner.de
> >  http://www.joachim-breitner.de/
> >
> > _______________________________________________
> > 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/20220307/6d1c1028/attachment.html>