Stefan, I thought you had a proposal a while back for splitting next into nextind/nextval, although it didn't really go anywhere.
I think there is an argument to be made for splitting out things that can be iterated only by mutation (such as Tasks) from the general case. On Thursday, June 12, 2014, Philippe Lavoie <[email protected]> wrote: > Hi, > Thanks for you answer. I am still hung up on a couple of details: > Are you saying that, in Julia, in order for an iterator to be efficient, > it has to be an immutable type? > Would it be possible to just use it like this: > iter = getacomplicatediter(myCollection) > (elt, current ) = next(myImmutableIter) > stopCondition = done(iter) > > I guess I don't understand what the additional argument/return value > "state" is for? > > Thanks, > Phil > > On Thursday, June 12, 2014 12:09:22 PM UTC-4, Stefan Karpinski wrote: >> >> Mutable state is lousy for performance. Since the iteration protocol is >> used for things as basic as a for loop count up from 1 to n, it has to be >> very fast. If it used a mutable iterator object, getting that to be fast >> enough would be a nightmare. Using explicit external state makes it easy to >> translate a for loop into very fast, efficient code, equivalent to what you >> would write by hand with a while loop. >> >> >> On Thu, Jun 12, 2014 at 11:59 AM, Philippe Lavoie <[email protected]> >> wrote: >> >>> Hi, >>> So I was seduced by a lot of things Julia had to offer and I found the >>> documentation really fun and helping. >>> >>> However, I do have some questions, one of them would be: "why iterator >>> functions pass state?". >>> In a more traditional language, you would address an iterator as such: >>> iter.next(), iter.done(), iter.popFront(), iter.front(), iter.empty(), >>> etc... >>> >>> I am curious to know why, in Julia, iterator functions pass around state: >>> init = start(iter) >>> (i, current) = next(iter, init) >>> done = (iter, current) >>> >>> First of all, I am not sure why a method called "start" would exist, >>> given the iterator might be provided by another function, like >>> "ascendingValues(myRedBlackTree)", which would return an iterator for >>> values in ascending order for example. >>> Second, given you have an iterator, why pass its state around instead of >>> just modifying it at every functional call, like traditionally (java, c++, >>> etc...). IMHO, the iterator interface should/could borrow from other >>> programming languages and could be something like: >>> done = isDone(iter) >>> next = next(iter) >>> >>> >>> >>
