This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
On Mon, Apr 28, 2003 at 10:15:39PM -0700, Per Bothner wrote:
> The iterator model is unclear to me.
> First, the name "iterator" may not be the best choice.
> When I use an "iterator" to iterate through a sequence,
> in most languages I change the location of the iterator,
> but the identity of the iterator object does not change.
> In the proposed API, iterators themselvs are immutable,
> and you move to a new position by getting a new iterator.
> This is reasonable for a (mostly-)functional language
> like Scheme, but perhaps "position" would be a better name?
Well, they are still iterators, the difference is that instead of an
iterator object which is mutated as in other languages, we behave
functionally, returning a new state object from iterator-next.
>
> My conclusion is the model is that there are N+2 iterators for
> a sequence of N elements. I guess this could be made to work,
> but it is different from what I'd expect. (Input ports follow
> the N+1 model.) I think there needs to be some motivation for
> this model, and a little exploration of the consequences.
There is a motivation for this model. It creates symmetry in the case
that a collection supports reversing the iteration direction. A program
written to walk backwards from within an iterator will have the same
appearance as one which walks forwards:
(if (not (iterator-at-end? i))
(begin (do-something)
(loop (iterator-next i))))
and
(if (not (iterator-at-start? i))
(begin (do-something)
(loop (iterator-previous i))))
There are a few other reasons for this model, which I will try to
remember when I leave work.
Scott
Attachment:
pgpdnYd4tqo3D.pgp
Description: PGP signature