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 data item "i", when in fact the proper approach is for the data item "i" to correspond to the old "state" and to lag one position behind the returned "state".) I no longer think there is a problem with the start/done/next paradigm in Julia.
--- Steve Vavasis On Wednesday, July 23, 2014 12:29:12 AM UTC+3, vav...@uwaterloo.ca wrote: > > Dear Julia users, > > As I have mentioned in earlier posts, I am working on a 2-3 tree > implementation of a sort-order dict, that is, a dict in which the (key, > value) pairs can be retrieved in the sort-order of the keys. According to > section 2.1.7 of the manual, "for i = I; <body> ; end" translates to: > > state = start(I) > while !done(I, state) > (i,state) = next(I,state) > <body> > end > > The more obvious way to implement the loop would be to put the body BEFORE > the 'next' statement, and at first I thought that maybe the manual has a > typo. But then I checked the file dict.jl, and I found indeed the code: > > done(t::ObjectIdDict, i) = is(next(t,i),()) > > So this means that every loop iteration over an ObjectIdDict requires two > calls to 'next', one as part of the call to 'done', and a second one to > actually advance the loop. > > I also looked at the code for 'done' for Dict in dict.jl, and it appears > to be buggy(??). It does not check whether everything after the current i > is deleted(??) > > For a 2-3 tree, the 'next' operation is logarithmic time, so requiring it > twice per loop iteration is undesirable. > > Can anyone shed light on why the Julia loop construction is implemented > this way, so that two separate calls to 'next' are necessary? I suppose > that it is possible with additional code complexity to cache the result of > the first call to 'next' inside the state, but what exactly is the > rationale for the current design? > > Thanks, > Steve Vavasis > >
