Re: ruby-dev summary 18711-18810

From: "Pit Capitain" <[e-mail]>

> Do you know implementations like (from Ruby CVS)
> rough/lib/generator.rb? Why do you think these are inefficient?

I haven't seen that (but I'll definitely take a look). I think generators
can be implemented efficiently. In my experience with generators in other
languages, the time efficiency is good enough, and depending on the
underlying language implementation, they can be costly of space since in
some implementations they require their own contiguous stacks (almost like
threads -- to support suspended C stacks in the underlying C code).

If Ruby has an efficient generator capability, it would be a good way to
implement "zip" without the space cost of creating an entire copy of all of
the pointers in all involved sequences.

BTW, I have quite a bit of experience with languages that support
generators, primarily with Icon whose generators are normally used at the
site of the generation (like Ruby's iterators) but can be also be captured
in a "co-expression" to be used anywhere and any time to grab values from
the generator (like Python's generators). Like Matz says, the Ruby iterator
mechanism is simpler and nicely handles 99% of the cases that usually come
up. On the other hand, in those relatively rare cases where when parallel
iteration requirements arise, the "use anywhere" variety of generator can
make the task much more pleasant.

Maybe Ruby could consider approaches like Icon's where iterators are
normally internal (like they are now), but can be converted to external for
those occasional needs (apologies if this has already been discussed to
death). I attached a small experimental Ruby class I wrote a long time ago
that implements something like this. The implementation uses threads and
queues, so is not very efficient. However, an API of this sort could
possibly be implemented efficiently at a lower level. Here is the
description from the top of the code:

#
# Creates an iterator object from an iterator method.
#
# Iterator objects do not replace Ruby iterator methods, but they extend
# their capabilities in certain ways:
#
# - The next value(s) can be obtained from anywhere in the program, not
#   just from the code block passed to the iterator method.
#
# - Multiple iterator objects can be active in parallel.
#
# Iterator creation examples:
#
#   i = Iterator.new((1..10).method(:each))
#   i = Iterator.new([11, 22, 33].method(:each_with_index))
#
# The iterator's values are retrieved as the array of arguments passed
# to the iterator method's block, for example:
#
#   list_element, index = i.get
#


Bob
(packing for a trip -- will be away from my email for a couple of weeks)