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 > 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 >>
