rfcs
rfcs copied to clipboard
haskell
Add Tuple Sections
Rendered version: https://github.com/quchen/rfcs/blob/tuple-sections/texts/0000-tuple-sections.rst
I'm in support of including TupleSections as they exist in GHC. However, I'd like to point out that this extension is in conflict with allowing trailing commas.
We do not allow trailing commas right now, do we? I don’t think that discussion has ever come to a conclusion. TupleSections is far older, and in my opinion more practical.
We do allow a trailing comma in import/export lists, but not elsewhere. My concern is that there is a segment of the community that wants wider support for trailing commas, which would be incongruous with TupleSections. There's no actual conflict -- we just wouldn't support trailing commas in tuples -- but it would be an exception to the general rule.
Just to reiterate: I'm in full support of this proposal. The trailing-commas point is just to note a potential reason why someone might not want this proposal.
I am in support of this proposal too---I think it fits very naturally with other sections.
(copied from the mailing list)
I have no objection to the proposal in the abstract, but I don't think the concrete proposal is completely fleshed out. I'd prefer to see the actual modifications to Haskell 2010 grammar, at least, before the final vote.
I was thinking that grammar changes are fairly straight-forward, namely simply allow for the expressions in a tuple to be optional.
aexp → ([exp1] , … , [expk]) (k ≥ 2)
Once we add this, we can remove the special qcon for tuples, as the tuple constructor ends up being the same as a tuple section where all expressions are omitted.
@blamario is this sufficiently clear?
Adding the grammar elements is a good idea, and we should probably keep this in mind for further proposals. I’ll add it within the next days.
@yav Shepherd? :-)
I'm mildly opposed to this.
If I were designing a language from the ground up, I would not include syntax sugar for tuples. In my experience with Haskell, they're a pretty, nice, and convenient way to invite space leaks into your code and get yourself tied up in product-blindness. It's almost always better to rewrite code using tuples to concrete datatypes with proper names.
In my experience with PureScript, datatypes like data a /\ b = a :/\ b work just as well for this case. (a :/\ b) is syntactically heavier than (a, b) (a neutral fact, as tuple use should probably be discouraged), but works just fine as an operator section [ (:/\ b), (a :/\) ] without any language extensions, and provides rather natural nesting: a :/\ b :/\ c :/\ d.
A tuple is, at heart, an arbitrary pairing of data. However, the Functor Foldable Traversable Comonad etc instances for tuples make them more suitable as a (tag, a), which might be more explicitly encoded as data Annotate ann a = Annotate { annotation :: ann, value :: a }. It's relatively simple to write these as operator sections: fmap ((,) ann) or fmap ((,,) a0 a1) so that the new value is the "functorial" value (to make up and abuse terminology).
It requires slightly more characters to insert something into the middle of a tuple. fmap (\a -> (a, x)) or fmap (\b -> (a, b, c)). The more experience I get with writing Haskell, the more I tend to prefer more verbose forms - aside from very simple cases, like filter (`Set.elem` xs), it is usually simpler, more easily extensible/traceable, and easier to read to use the longer form. The more concise point-free form is sometimes a win, but only in the simplest cases.
TupleSections is an extension that encourages the use of large tuples and arbitrarily ordered tuples, and it makes worst practices easier. I'm happy with it being an extension that I can ignore at leisure and ban from codebases I maintain with tools like HLint. If this becomes a language feature, then it will require slightly more work from me to ensure that it doesn't show up in any of my code bases.
Fwiw, I strongly disagree. Tuples are an enormously ingrained part of idiomatic Haskell. You can have a language where they're not idiomatic, but that language will not be Haskell. Changes should flow with the direction of the language. They're also, in surveys taken over the years, enormously popular and convenient.
I also feel that tuples are an idiomatic part of Haskell. My personal view is that tuple sections are an important part of any future language standard.
When the committee discussed this at ICFP a few years ago there was wide agreement.
Is anyone wanting to veto? If not let’s just move forward with it.
On Tue, Jun 18, 2019, at 6:37 PM, gbaz wrote:
Fwiw, I strongly disagree. Tuples are an enormously ingrained part of idiomatic Haskell. You can have a language where they're not idiomatic, but that language will not be Haskell. Changes should flow with the direction of the language. They're also, in surveys taken over the years, enormously popular and convenient.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/haskell/rfcs/pull/6?email_source=notifications&email_token=AAGDUB6ON6D2XVZ7MMMVBJTP3FPS3A5CNFSM4CMA7BI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYAFE6I#issuecomment-503337593, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGDUB5DWEZO2DJYOEH5253P3FPS3ANCNFSM4CMA7BIQ.
Sure, and I wouldn't dream of making a proposal to remove tuples from Haskell. That they're overused and prone to Boolean blindness isn't an argument for removing them any more than it is an argument for removing Bool or Maybe or Either, types which are just as susceptible to these problems.
I couldn't imagine Haskell without TupleSections. This language extension is a regular in my source files. (Along with LambdaCase.)
I find this frustrating because I’m strongly negative on this, but I feel my objections are impractical to address at this time, so I’m effectively cornered into neutrality.
I want to object on the grounds that TupleSections makes improving support for trailing commas harder, and it’s legible only in the small, scaling poorly to higher numbers of elements or higher numbers of omitted elements.
However, I believe there’s no path forward for trailing commas without some fundamental changes to Haskell’s grammar; and I think people almost exclusively use TupleSections in the small anyway: the vast majority of tuple sections I’ve seen in the wild were (x,) or (,x), although in my opinion that’s not much of an improvement over (,) x or flip (,) x.
