This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 are here. Eventually, the entire history will be moved there, including any new messages.
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
Description: PGP signature