[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