Why does 'zip' ignore the dangling tail of the collection?

Question

C#, Scala, Haskell, Lisp and Python have the same zip behaviour: if one collection is longer, the tail is silently ignored.

It could be an exception thrown as well, but I didn't heard of any language using this approach.

This puzzles me. Does anyone know the reason why zip is designed that way? I guess for new languages, it is done because other languages do it this way. But what was the root reason?

I am asking here factual, historic-based question, not if somebody likes it, or if it is a good or bad approach.

Update: If I was asked what to do, I would say -- throw an exception, pretty similarly to indexing an array (despite "old" languages did all kind of magic, how to handle out of bounds index, UB, expand array, etc).

Answer 1

It's almost always what you want, and when it isn't, you can do the fill yourself.

The main issue is with lazy semantics you don't know the length when you first start the zip, so you can't just throw an exception at the start. You would need to first return all the common elements, then throw an exception, which wouldn't be very useful.

It's also a style issue. Imperative programmers are accustomed to manually checking boundary conditions all over the place. Functional programmers prefer constructs that can't fail by design. Exceptions are extremely rare. If there's a way for a function to return a reasonable default, functional programmers will take it. Composability is king.

Answer 2

Because there's no obvious way to complete the tail. Any choice on how to do it would result in a non-obvious tail.

The trick is to explicitly lengthen your shortest list to match the length of the longest with values you expect.

If zip did that for you, you couldn't know what values it was filling in intuitively. Did it cycle the list? Did it repeat a mempty value? What is a mempty value for your type?

There's no implication in what zip does which one could use to intuit the way the tail would be lengthened, so the only reasonable thing to do is work with the values available rather than making some up your consumer may not expect.

---

Also remember you're referring to a very specific well known function with specific well known semantics. But that doesn't mean you can't make a similar but slightly different function. Just because there's a common function that does x, doesn't mean you can't decide for your given purpose you want to do x and y.

Though remember the reason this and many other common FP style functions are common, is because they're simple and generalized so you can tweak your code to use them and get the behaviour you want. For instance, in C# you could just

IEnumerable<Tuple<T, U>> ZipDefaults(IEnumerable<T> first, IEnumerable<U> second)
{
    return first.Count() < second.Count()
        ? first.Concat(Enumerable.Repeat(default(T), second.Count() - first.Count())).Zip(second)
        : first.Zip(second.Concat(Enumerable.Repeat(default(U), first.Count() - second.count())))
}

Or other simple things. FP approaches make modifications so easy because you can reuse pieces as well as having implementations be so small as above that creating your own modified versions of things is exceedingly simple.