What problem does this solve?
.map, .filter, and friends eagerly materialize a new list every time. Chain three of them together and you allocate three intermediate lists that get thrown away immediately. That's wasteful for large collections and means you can't work with infinite sequences at all.
Proposed solution
Make iterable methods return lazy lists instead of materializing. Computation only happens when you consume the result (iterate, collect, index into it, etc.).
.map, .filter, .take, .skip return lazy wrappers- Haskell-style memoization (computed values are cached)
- Ranges as lazy sources (
1..1000000 doesn't allocate a million-element list)
- Explicit
.collect() or .to_list() to force materialization
Current state
No design document exists for this yet. The TODO references a lazy lists RFC but no file has been written. The current iterable lowering (1600+ lines) always materializes to concrete lists using eager loop scaffolds with index iteration and result collection. This needs an RFC before any implementation starts.
Alternatives considered
Could keep eager evaluation and just optimize the common cases (fuse map/filter chains in the compiler). That helps performance but doesn't enable infinite sequences or streaming patterns.
Area
Runtime / codegen
Depends on codegen maturity since this changes the return type of core iterable methods.
What problem does this solve?
.map,.filter, and friends eagerly materialize a new list every time. Chain three of them together and you allocate three intermediate lists that get thrown away immediately. That's wasteful for large collections and means you can't work with infinite sequences at all.Proposed solution
Make iterable methods return lazy lists instead of materializing. Computation only happens when you consume the result (iterate, collect, index into it, etc.).
.map,.filter,.take,.skipreturn lazy wrappers1..1000000doesn't allocate a million-element list).collect()or.to_list()to force materializationCurrent state
No design document exists for this yet. The TODO references a lazy lists RFC but no file has been written. The current iterable lowering (1600+ lines) always materializes to concrete lists using eager loop scaffolds with index iteration and result collection. This needs an RFC before any implementation starts.
Alternatives considered
Could keep eager evaluation and just optimize the common cases (fuse map/filter chains in the compiler). That helps performance but doesn't enable infinite sequences or streaming patterns.
Area
Runtime / codegen
Depends on codegen maturity since this changes the return type of core iterable methods.