More NonEmpty zips, again

[Bodigrim]

(Copying @treeowl's #83 as a new proposal, as suggested)

Data.List.NonEmpty offers zip, zipWith, and unzip. Data.List, on the other hand, offers each of these up to arity 7. I propose to add all the rest for NonEmpty:

• zip3 ... zip7
• zipWith3 ... zipWith7
• unzip3 ... unzip7

[ChickenProp]

Presumably the ones to add are instead

• zip3 ... zip7
• zipWith3 ... zipWith7
• unzip3 ... unzip7

? Since the 2 variants don't have 2 in the name and already exist.

[Bodigrim]

Thanks, edited.

[Bodigrim]

@TeofilC if there are no comments / suggestions, I'm happy to prepare an MR.

[Bodigrim]

@TeofilC just a gentle ping.

[TeofilC]

Sorry I thought I had already replied. An MR sounds good. And then we can go to a vote pretty quickly, since this seems to be pretty uncontroversial so far

[TeofilC]

Any more thoughts about this @velveteer @Daniel-Diaz @ChickenProp @noughtmare @mpscholten @doyougnu @parsonsmatt @jeltsch @rickowens ? I wanted to check cause there hasn't been much discussion here, and I'm not sure if it's because it's uncontroversial or if folks missed it

[rickowens]

I am in favor of this idea, on the basis of parity, and making it that much easier for a user to switch from List to NonEmpty.

[jeltsch]

I think that using tuples with more than three elements is typically bad style. Tuples in general suffer from the problem that they don’t tell you what those bundles of elements mean. Usually, defining a custom data type is the appropriate solution. There are some cases where pairs have been used traditionally (for example, key–value pairs and results of the functions implementing State computations) and thus the meaning of those pairs is fairly clear from experience. There may be appropriate uses of triples, but already quadruples are something which I don’t see a proper use for. Who is using septuples?

[phadej]

@jeltsch ... and to zip into your custom data type of four fields you'll need zipWith4.

[jeltsch]

@jeltsch … and to zip into your custom data type of four fields you’ll need zipWith4.

Oh, yes, you’re right: zipWith4 is a different matter compared to zip4 and unzip4.

Well, I guess I’m in favor of this proposal then. Adding zipWith flavors up to zipWith7 but leaving out the corresponding zip and unzip flavors would leave awkward holes in the offered selection of operations. The actual problem is the existence of tuple types, not the higher arities.

[doyougnu]

I generally don't like heavy tuple styles but don't want to limit others. +1

[ChickenProp]

Who is using septuples?

I've used tuples around that size for database serialization and deserialization. Not zipped, as far as I remember.

I guess I am curious to see where whether the list functions at 7 get used... a search shows a handful of packages defining functions named zip7, sometimes in terms of existing ones, but then bdcs uses Data.List.zip7 for real. And the context seems to be database interaction. My guess is that defining a separate data type would have also needed defining a bunch of instances, so the author figured tuples were fine. I'd likely have done similar.