It would not be often useful to have it count up from 1 or zero up to or below the value; I would not have designed it that way. In many situations you don't know the upper limit of what is enumerated; it comes implicitly from the lengths of other sequences or in other ways.
It's also less inefficient, because the value has to be converted to an iterator object that knows about the range, and keeps track of the state.
In TXR Lisp, certain objects are self-iterable, like characters, numbers and good old conses.
1> (iter-begin "abc")
#<seq-iter: a031a10>
2> (iter-begin 3)
3
3> (iter-begin '(a b c))
(a b c)
To iterate a string, we need to obtain a seq-iter object, but for 3 and (a b c), we do not. With these objects, we have all the state we need in order to iterate.
4> (iter-more 3)
t
5> (iter-item 3)
3
6> (iter-step 3)
4
7> (iter-more '(a b c))
t
8> (iter-item '(a b c))
a
9> (iter-step '(a b c))
(b c)
10> (iter-more *1)
t
11> (iter-item *1)
#\a
12> (iter-step *1)
#<seq-iter: a031a10>
13> (iter-item *1)
#\b
iter-step may or may not destructively update its argument, so you always have to capture the return value and forget about the original.
You can see how for a list, iter-more is equivalent to (not (null ...)), iter-item is just car, and iter-step is just cdr.
There is also lazy processing in TXR Lisp. E.g. lazy mapcar which is mapcar*. The following will only read the first few lines of the syslog, returning instantly:
14> (take 3 [mapcar* cons 1 (file-get-lines "/var/log/syslog")])
((1 . "Jul 23 00:09:54 sun-go systemd[1]: openvpn@client.service: Service hold-off time over, scheduling restart.")
(2 . "Jul 23 00:09:54 sun-go systemd[1]: openvpn@client.service: Scheduled restart job, restart counter is at 1044619.")
(3 . "Jul 23 00:09:54 sun-go systemd[1]: Stopped OpenVPN connection to client."))
It's also less inefficient, because the value has to be converted to an iterator object that knows about the range, and keeps track of the state.
In TXR Lisp, certain objects are self-iterable, like characters, numbers and good old conses.
To iterate a string, we need to obtain a seq-iter object, but for 3 and (a b c), we do not. With these objects, we have all the state we need in order to iterate. iter-step may or may not destructively update its argument, so you always have to capture the return value and forget about the original.You can see how for a list, iter-more is equivalent to (not (null ...)), iter-item is just car, and iter-step is just cdr.
There is also lazy processing in TXR Lisp. E.g. lazy mapcar which is mapcar*. The following will only read the first few lines of the syslog, returning instantly: