[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

iteration iteration

All this discussion of storage management has inspired me to think
about one of the worst offenders:  iterators.  I had an idea while
talking to Mr Hill which is still not fully developed, but I'll post it.

The current Iterator objects were designed to represent the state of
an iteration.  With these, I can find the best state of an iteration
from which to start some particular operation.  The real driving
reason behind the statelessness (anarchy?) of Iterators was in the
rebalance algorithms of enfilades and ents.  Rebalancing needs to
iterate over a collection of crums, while dynamically changing the
collection.  The only solution that comes to mind is to have
side-effect free collections, and just change the collection upon
which I'm iterating.  The insight that occurred to me in Mr Hill's
office was that just because the collection is side-effect free
doesn't require the representation of the state of the iteration to be
side-effect free.

Using side-affectable IterationStates to iterate side-effect free
collections requires the abililty to tell the iteration to start using
a newly generate collection.  

Shall we talk about it tonight?  (Another one rides the bus...).