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

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 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 wrote:

Hi,

...

There’s also a new alternative described in the proposal. Here are our

Am Montag, dem 28.02.2022 um 22:31 +0300 schrieb Vladislav Zavialov (int-index): 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@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee