Test cases: (some input cases are just to make sure there are no infinite runs)....
(forstep i 5 10 1 (prn i))
(forstep i 5 10 2 (prn i))
(forstep i 10 5 2 (prn i))
(forstep i 5 10 -2 (prn i))
(forstep i 0 1 0 (prn i))
(forstep i 1 0 0 (prn i))
(forstep i -2 2 1 (prn i))
(forstep i 2 -2 1 (prn i))
(forstep i -4 2 2 (prn i))
(forstep i -4 2 -2 (prn i))
(forstep i 4 -2 -2 (prn i))
(forstep i 4 -2 2 (prn i))
That being said, I don't understand why changing 'for' this way would create problems for you, or why you want
(for i 1 0 (prn i)) to return nil.
also, I still think it would be nice for arc to support keyword arguments (hint, hint pg - though he's probably not reading this), then I could have 'step' as an optional arg with a default. i.e....
(mac for (v start end (o step 1) . body)...
could allow:
(for i 20 5 (prn i)) and also something like: (for i 20 5 step:2 (prn i))
A much better alternate version too. The redundant code in my hacked version was obvious and ugly, but I struggled reducing it to a simpler form... Thanks!
I made a few slight adjustments though, as it failed 2 of my test cases (however unlikely they are to occur, infinite runs scare me).
That being said, I don't understand why changing 'for' this way would create problems for you
Perhaps I'm doing i from 1 to the number of things I have, and sometimes I have zero things.
Actually though it was a bit silly of me to suggest "forstep" when your version of "for" was doing what you wanted it to do. It's not a version that I'd want to use in my code, but that's no reason for you not to have your version.