Dear Julia users,
Thank you for all your thoughtful replies on this matter. Indeed, you are
all correct, and I misunderstood the construct. (The point that confused
me was that in the call (i,state)=next(I,state), I mistakenly assumed that
the returned state should correspond with returned
Glad it makes sense. Maybe we could explain that better.
On Jul 23, 2014, at 3:20 PM, vava...@uwaterloo.ca wrote:
Dear Julia users,
Thank you for all your thoughtful replies on this matter. Indeed, you are
all correct, and I misunderstood the construct. (The point that confused me
Tim,
The fact that 'next' is called before the loop body rather than after means
that the 'done' predicate must provide an answer to the question: if
'next' is called on the current state, then would the result be the end of
the data structure? The obvious way to answer that question is to
Thanks for clarifying. While I know exactly what you're talking about, and I
wasn't around when iterators were designed, I've always assumed that the
current behavior follows from two principles: (1) `done` must evaluate to a
boolean, and (2) the `item` should not leak out of the scope block
Two separate calls to next certainly aren't in general necessary, and I
haven't hit any issues implementing the iterator interface before. In fact,
it felt quite natural in the end.
I suspect that no matter which way you do the iteration interface, you'll
be able to find an example where you'd
The other point to make is that if you find it more natural to do your
incrementing inside done, there's no rule saying that next has to do any
actual work. You can cache the item somewhere and just have next fetch it.
--Tim
On Tuesday, July 22, 2014 06:13:25 PM Iain Dunning wrote:
Two
it can however to better for done() to do no work, but to have next
actually compute the next+1 state:
start(x) = next(x)
next(x,i) = (i, next(x))
done(x,i) = (i===sentinel)
this makes next somewhat more expensive to call repeatedly, but has the
benefit that the user can hold onto a reference to
