Make List.zipWith as lazy as expected #492

aspiwack · 2025-10-21T11:47:34Z

Fixes #491

tbagrel1

I think zipWithK is very close to a dual-fold/bi-fold/zip-fold (not sure if there is a standard name), if we fuse the f and cons functions into one of type a -> b -> r -> r. Maybe it would make for a more general/intuitive function?

tbagrel1 · 2025-10-24T08:10:38Z

src/Data/List/Linear.hs

+  where
+    go :: [a] %1 -> [b] %1 -> r
+    go [] [] = nil
+    go (a : as) [] = lefta a as


It's not entierely clear why the left{a,b} functions are taking head and tail as separate arguments. I guess the motivation is to make a NonEmpty list in zipWith' without having to call NonEmpty.fromList?

You could say that. Or equivalently, that lefta has all the available information. Or equivalently, that it makes invalid states unrepresentable. It's the natural type for this function don't you think?

src/Data/List/Linear.hs

test/Test/Data/List.hs

tbagrel1 · 2025-10-24T08:15:10Z

src/Data/List/Linear.hs

+    go [] (b : bs) = leftb b bs
+    go (a : as) (b : bs) = cons (f a b) (go as bs)

 zipWith3 :: forall a b c d. (Consumable a, Consumable b, Consumable c) => (a %1 -> b %1 -> c %1 -> d) -> [a] %1 -> [b] %1 -> [c] %1 -> [d]


Why does zipWith3 doesn't get the same treatment with a zipWithK3?

Because there's no zipWith3' with rests. And that, in turn, is because we didn't give it a type (using Either is a bit of a shortcut for zipWith', maybe it was a bad shortcut).

We could make a zipWith3K if we decide to export it.

tbagrel1 · 2025-10-24T08:16:39Z

src/Data/List/Linear.hs

+  zipWithk f (:) [] consume2 consume2
+  where
+    consume2 :: forall x y z. (Consumable x, Consumable y) => x %1 -> y %1 -> [z]
+    consume2 x y = x `lseq` y `lseq` []


In zipWith3 you do (x, y) `lseq` [] instead, any reason to prefer one or the other?

I don't think it makes much difference after optimisation. In principle, even without optimisation x `lseq` y `lseq` [] is going to be one fewer allocation.

aspiwack

I really thought I replied at the time. Got consumed by silly tasks in the meantime, let me address the comments quickly today and then merge.

aspiwack · 2025-11-13T05:55:30Z

src/Data/List/Linear.hs

+  zipWithk f (:) [] consume2 consume2
+  where
+    consume2 :: forall x y z. (Consumable x, Consumable y) => x %1 -> y %1 -> [z]
+    consume2 x y = x `lseq` y `lseq` []


I don't think it makes much difference after optimisation. In principle, even without optimisation x `lseq` y `lseq` [] is going to be one fewer allocation.

src/Data/List/Linear.hs

aspiwack · 2025-11-13T05:57:25Z

src/Data/List/Linear.hs

+  where
+    go :: [a] %1 -> [b] %1 -> r
+    go [] [] = nil
+    go (a : as) [] = lefta a as


You could say that. Or equivalently, that lefta has all the available information. Or equivalently, that it makes invalid states unrepresentable. It's the natural type for this function don't you think?

aspiwack · 2025-11-13T05:58:52Z

src/Data/List/Linear.hs

+    go [] (b : bs) = leftb b bs
+    go (a : as) (b : bs) = cons (f a b) (go as bs)

 zipWith3 :: forall a b c d. (Consumable a, Consumable b, Consumable c) => (a %1 -> b %1 -> c %1 -> d) -> [a] %1 -> [b] %1 -> [c] %1 -> [d]


Because there's no zipWith3' with rests. And that, in turn, is because we didn't give it a type (using Either is a bit of a shortcut for zipWith', maybe it was a bad shortcut).

We could make a zipWith3K if we decide to export it.

test/Test/Data/List.hs

aspiwack · 2025-11-13T06:39:49Z

I think zipWithK is very close to a dual-fold/bi-fold/zip-fold (not sure if there is a standard name), if we fuse the f and cons functions into one of type a -> b -> r -> r. Maybe it would make for a more general/intuitive function?

I'd missed this. Yes, it is a zipWith combined with a fold (I'm not sure there's a standard name). Your proposal would work fine, but probably would yield slightly worse Core for zipWith with an extra closure that may be hard to optimise away. Let me have a look.

aspiwack · 2025-11-13T07:06:49Z

I think zipWithK is very close to a dual-fold/bi-fold/zip-fold (not sure if there is a standard name), if we fuse the f and cons functions into one of type a -> b -> r -> r. Maybe it would make for a more general/intuitive function?

I'd missed this. Yes, it is a zipWith combined with a fold (I'm not sure there's a standard name). Your proposal would work fine, but probably would yield slightly worse Core for zipWith with an extra closure that may be hard to optimise away. Let me have a look.

I was wrong, the zip-fold thing yields the very same code. Excellent idea!

There is no such function in the Hoogle database at all. I'll name it zipFold, I think. And it means I can export it.

aspiwack · 2025-11-13T08:01:56Z

Ok. I'll merge when green.

I did export the zipFold function now that it looks like a normal function.

I didn't write a zipFold3 function because it has a scary number of potential shapes of leftover functions (in general for zipFoldN, there would be $2^N-1$ potential leftover shapes). I don't know how to represent these options in a sane way.

I'll cut a minor release with this fix on Tuesday, so we have until then to figure out if there's a scalable way to represent leftovers wider zip functions.

tbagrel1 · 2025-11-13T09:09:55Z

Thanks for taking time to address my comments! LGTM

aspiwack mentioned this pull request Oct 21, 2025

zipWith throws NonTermination exception #491

Closed

aspiwack force-pushed the lazy-zipwith branch from 972fb7d to 08a229a Compare October 21, 2025 11:59

tbagrel1 approved these changes Oct 24, 2025

View reviewed changes

aspiwack commented Nov 13, 2025

View reviewed changes

aspiwack added 2 commits November 13, 2025 15:32

Laziness tests for zipWith* functions

632cfb1

Cleanup an unused extension

bb6fe7b

aspiwack force-pushed the lazy-zipwith branch 2 times, most recently from 69a4215 to b73d0f4 Compare November 13, 2025 07:56

aspiwack enabled auto-merge November 13, 2025 07:57

Make List.zipWith as lazy as expected

cab9d3e

aspiwack force-pushed the lazy-zipwith branch from b73d0f4 to cab9d3e Compare November 13, 2025 08:15

aspiwack merged commit c10e8fa into master Nov 13, 2025
13 checks passed

aspiwack deleted the lazy-zipwith branch November 13, 2025 08:21

Make List.zipWith as lazy as expected #492

Make List.zipWith as lazy as expected #492

Uh oh!

Conversation

aspiwack commented Oct 21, 2025

Uh oh!

tbagrel1 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aspiwack left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

aspiwack commented Nov 13, 2025

Uh oh!

aspiwack commented Nov 13, 2025

Uh oh!

aspiwack commented Nov 13, 2025

Uh oh!

Uh oh!

tbagrel1 commented Nov 13, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants