get rid of zipwith in favor of map

[gilch]

Ref. #240

What is zipwith doing that map doesn't already do? I tried zipwith's unit tests using map instead. Works perfectly:

=> (import operator)
=> (list (map operator.add [1 2 3] [3 2 1]))
[4, 4, 4]
=> (list (map operator.sub [3 7 9] [1 2 4]))
[2, 5, 5]

If zipwith has some other feature I'm not seeing, it should be unit tested. Otherwise, can we get rid of it please?

[zackmdavis]

I'm in favor of removing zipwith; the duplication with map has been noted previously. 8e4b211 actually removes the original implementation and replaces it with (setv zipwith map), but somehow we seem to have ended up with both versions on master? (One wonders when and how that happened.)

[algernon]

👍

Anyone want to fire up a PR to drop zipwith?

[refi64]

Yeah, this was entirely my fault. Up till then, I had used C++ and Haskell more than Python (even though that's changed), so I never realized that map already took multiple iterables. (And I'm guessing the people that liked the zipwith PR didn't realize it either...)

[gilch]

#929 will also remove zipwith.

I never realized that map already took multiple iterables.

I imagine that most Hy users not familiar with Python would miss that. Maybe even some Python users haven't noticed. I'm not sure what to do about that. It's still redundant and should be removed. Perhaps we could point it out in the tutorial or something. Perhaps we should re-document all Python builtins, or at least feature link to that page in the Python docs prominently.

Haskell's prelude and Clojure's core have a lot of useful functions for FP. I wonder if we should port more of them to Hy core. I also wonder how much of that Python already supports somehow.