Why is zipWith3 implemented as it is?

[andrewthad]

Original issue by @treeowl:

zipWith3 is implemented using next rather than acting streamish the way zipWith does. Is there a reason for this? What goes wrong if zipWith3 is implemented using zipWith or zipsWith?

[andrewthad]

I assume that when you say "acting streamish", you're talking about pattern-matching on the Stream. I would take a PR that reimplemented zipWith3 using zipWith or zipsWith since the resulting code would probably be much shorter.

[ivan-m]

I would prefer using next and similar functions when using Streams to make function implementation independent of the data structure's implementation. This might be less of an issue in this library, but we should encourage people not to import the .Internal module (because it's Internal), but seeing the internals being used everywhere internally makes it harder for third parties to see how else they can implement such functionality.

Specifically regarding this issue: I don't think it's possible to implement zip3 using zipWith due to the extra Monad requirement. Maybe if we had:

zipsWithM :: (Monad m, Functor f, Functor g, Functor h) => (forall x y. f x -> g y -> m (h (x, y))) -> Stream f m r -> Stream g m r -> Stream h m r
zipsWithM = ...

(That said, I'm not sure if it's even possible to implement zipWith using zipsWith due to the h (x,y) requirement; it seems to type-check if we have it as forall x y z. f x -> g y -> h z instead.)

[ivan-m]

The behaviour of zipsWith also differs from zipWith: the former will evaluate both Streams at the same time; the latter only evaluates the latter if the former has a value.

[chessai]

The behaviour of zipsWith also differs from zipWith: the former will evaluate both Streams at the same time; the latter only evaluates the latter if the former has a value.

is this true? zipsWith also seems to terminate upon an empty left-stream as well.