// Would you be happy if you hadn't looked at the code? Would
// you be happy if Ruby continuations were really really fast?
// Would you be happy if these generator objects were built-in
// to the Ruby C api and the implementation were effective
// obscured from you?
//
// What is it, exactly, you want Ruby to do?
At this point I need to ask you a question -
How do internal iterators work? How do they manage state? I havent seen
a description of this anywhere.
I know about creating objects for iteration. How do the internal
itertors differ from these?
I had thought that ruby would create an object for iteration, by
examining the proc code. It would then live in the context of the Ruby
GC like all objects and maintain state. The only difference I saw with
the 'internal' iterator is that since the syntax of ruby limits the
usage of the iterator to an explicit code block that catches it, the
details of the itertor object have been hidden from the user.
Which is to say that it is 'internal' only in the sense that
traditionally there was no need to give anyone explict access to the
object. The moment the idea of using multiple iterators in tandem is
considered, this assumption of hiding the object does not seem like the
right approach. The correct solution would have been to expose the
iterator object itself.
If however internal iterators are implmented in some way that have
different semantics from normal objects, then wrapping with
continuations is an acceptable solution for what is a design limitation
in the language. Wrapping itertors in continuations should not be
accepted way to do this in the language when there is a simpler
alternative possible.
So you see I really need to understand how internal iterators work,
before taking this ahead.
See the difference I see is that I see this as something the language
should have solved and not the library.
Roshan