Norbert Hajagos (Oct 27 2023 at 15:02): Norbert Hajagos (Oct 27 2023 at 15:02):I think rust iterators work the way I describe below, but not sure. Are you thinking of providing a solution to this:
I could phrase it way more generally, but you might already be thinking about this, so no need for it.
When I want to take an elemenet from a list after some transformation, I want to only do the transformations that are necessary with the built in list functions.
findInDoubled = \ l, needle -> List.map l (\x -> x*2) |> List.findFirst (\x -> x == needle)
findInDoubled [1,2,3,4] 4
Here, we wouldn't need to transform the elements 3, 4 if the findFirst function were to execute after every doubling. Essentially, it would be a "pull system", where (semantically) findFirst asks for an element from the List.map, until it finds the one. Right now, it is only doable with walkUntil.
Brendan Hansknecht (Oct 27 2023 at 18:33):I don't think we have really discussed it much at all
Ayaz Hafiz (Oct 27 2023 at 18:41):I don't think we intend to offer an exterior-iterator interface like Rust's because of the type complexity that usually comes with. But we do intend to implement deforestation/stream fusion (e.g. https://www.cs.tufts.edu/~nr/cs257/archive/duncan-coutts/stream-fusion.pdf) at some point, and have automatic support for Lists as a result.
Ayaz Hafiz (Oct 27 2023 at 18:42):In a userspace library, you can also implement the desired lazy behavior here with internal iterators (i.e. passing closures to an interface like walkUntil), but it doesn't compose very well.
Norbert Hajagos (Oct 30 2023 at 16:58):Hope the thank you note isn't too late. Deforestation seems very cool. It doesn't address my original problem, but it deffinetly makes me confident that one can generally just pipe the list to the next List function and not worry about performance. Mutch appreciatetion!
Last updated: Jun 16 2026 at 16:19 UTC