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

Re: enum protocol suggestion




On Wednesday, November 20, 2002, at 02:18  AM, Smelly Pooh wrote:
> I think nxt and now should be the one method unless there's a reason to
> split them
>
> (rep loop (enum)
>   (unless (fin? enum)
>     (nxt enum)
>     (post "%s\n" (now enum)) ) )
>
> is less elegant than
>
> (rep loop (enum)
>   (unless (fin? enum)
>     (post "%s\n" (nxt enum)) ) )

Two reasons not to combine them:
1) There is often a need to look at the current object without using it 
up.
2) The reason nxt doesn't return the current object is that we thought 
it'd be nice if enumerators weren't mutable but rather returned a new 
object each time. However, that is clearly not feasable to do unless 
the optimizer is smart enough to optimize away all the extra 
allocations (which, of course, is a hard problem), so currently the 
enumerators mutate. However, the interface is still defined *as if* 
enumerators did not mutate themselves. This means that nxt is defined 
to return the enumerator pointing to the next element (which of course 
really means it returns itself currently). It could return a tup of 
both the current element AND the new enumerator, but that would not be 
easier to deal with in any way.

I don't see it as a big problem, because, even better than either of 
those examples is:
(for ((x some-collection))
   (post "%s\n" x))

BTW, the correct way to write it without the for macro is (you can also 
see this by pasting the previous code into the listener wrapped by 
(macro-expand ...))

(rep loop ((e (enum some-collection)))
   (unless (fin? e)
     (post "%s\n" (now e))
     (loop (nxt e))))

james