Stream: ideas

Topic: Num.walkRange

Richard Feldman (Dec 10 2023 at 18:26):

so we have List.range but sometimes all I want to do is to walk over a range. It would be both more concise and also better for performance to have a Num.walkRange which did this without creating an intermediate list:

Num.walkRange : {
        start : [At (Num a), After (Num a)],
        end : [At (Num a), Before (Num a), Length Nat],
        step ? Num a,
    }*,
    state,
    (state, Num a -> state)
    -> state

thoughts?

Anton (Dec 10 2023 at 18:43):

I think it would read nicer to have it split up into range and walk. It seems like a compiler optimization could improve the performance easily.

LoipesMas (Dec 10 2023 at 18:50):

Are we planning on having something like iterators/generators? That could solve the performance issue

Richard Feldman (Dec 10 2023 at 18:51):

the plan is not to have something like those

Richard Feldman (Dec 10 2023 at 18:51):

and yeah it's true that optimizations in the future should make the perf equivalent

Brendan Hansknecht (Dec 10 2023 at 18:54):

I think we should only add that if it is for perf reasons.

Brendan Hansknecht (Dec 10 2023 at 18:54):

Otherwise just List.range |> List.walk

Kevin Gillette (Dec 10 2023 at 19:10):

I think Num.walk is pretty clear name? There's not really any other meaningful basic walk you can do over numbers.

I would expect that a walk over a range is a pretty-straightforward pattern to optimize in theory, but walking over a range is a common enough need to be worth its own function.

timotree (Dec 10 2023 at 20:39):

I imagine that Num.walk n would walk from 0 to n rather than taking an arbitrary range

timotree (Dec 10 2023 at 20:42):

You could also have Num.iterate : Num *, state, (state -> state) -> state where e.g. Num.iterate 2 x f is f (f x)

Brendan Hansknecht (Dec 10 2023 at 21:00):

Ah, a generic power functions. Maybe better named repeat?

Last updated: Jun 16 2026 at 16:19 UTC