Roshan James
3/15/2005 3:46:00 PM
// def fib
// a = 1
// b = 0
// yield 0
// while true
// x = a + b
// yield x
// a = b
// b = x
// end
// end
//
// fib { |n| puts n; break if n > 100 }
//
// All the state (a, b, and x) is in the iterator method.
//
// So the difference between external and internal iterators
// is: rather than repeatedly calling an "step" method on an
// "iterator object" and doing something with the result, you
// call an "iterator method" once, and pass it a lexical
// closure (in Ruby, a Proc object), and *it* then calls the
// Proc on each element.
William, what you are saying is that a closure of the caller's state is
passed to iterator. Which means that the iterator can be a normal method
on the stack?
I had always thought that the caller is a regular method and the callee
(the iterator) preserves state as an object. Here since the lexical
closure of the caller is what is used grab state... all methods that
call iterators are automatically mapped to some sort of object?
Is there something literature I can read about this?
If it is the caller that is modified by the language rather than the
callee, then it is evident why we need to wrap iterators in
continuations to grab their state.
As a matter of fact, it is evident why the language never had a
provision for lock-step iteration, because the if the iterator expects a
closure, then ever closure that can be passed to it has to be bound by a
certain siganture.
Which means that a hopeful syntax like
foo()|bar() {|from_foo|from_bar|
//single itertor block
}
...would not be easy to implement.
Hmm.. Interesting.
Roshan