Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add lazyFoldLeft #18
This PR adds a new
This method addresses a tension that currently exists with using folds in Scala. Lazy right folds are preferable in many ways as a building block for specific folds because they support efficient implementation of methods like
This problem has been addressed in various ways including variations of folds that allow the caller to explicitly signal termination (e.g.
First, they can require more work from the caller to explicitly specify early termination conditions when it should be implied by the operation itself. For example, when implementing
But the early terminating nature of the fold is really inherent in the
Second, these solutions require some additional boxing, either in terms of
This implementation of
In terms of soundness, we can show that for any pure function
My benchmarking also indicates that the performance cost of using a lazy left fold instead of a strict one is relatively low. Essentially the only additional work in traversing each element is setting and getting a boolean value.
So it seems like this could be a very useful method allowing us to implement a wide variety of methods in a relatively efficient way. I added some basic tests but didn't see the infrastructure for property-based testing or benchmarks. I'm happy to add those if that is helpful.
Thanks a lot for the detailed description!
How does it compare with the cost of using
Here are some benchmarking results. I did two benchmarks. The first looks at adding a list of numbers from 1 to 50,000. The strict left fold is the fastest as we would expect. The lazy left fold is slightly faster than using
The second benchmark looks at determining whether there is a number greater than 50,000 in a list of numbers from 1 to 100,000. The specialized
So overall I think we can say that the lazy left fold is as fast as using
From a technical perspective, we can write any expression using
So then it comes down to a more subjective question of what kind of API we want to provide.
What do you think?
Thanks again for your benchmarks and detailed explanations.
I have a slight preference to keep just
Well your example with
If we take your exists example:
Maybe this example won't be so bad if we use
Though on the other hand it does seem nice, for completion, to have
@julienrf That makes sense to me. Would you like me to update the PR accordingly?
@joshlemer I think the advantage of not having to use
Jul 30, 2019
1 check passed
Thank you @adamgfraser for contributing!
There is no specific roadmap, the goal of this project is to be a hub for good collection-related utilities. Feel free to help getting open PRs merged, to submit new PRs closing exsting issues, or to suggest new ideas.