Re: RFC: Generators v2

[Stephen J. Turnbull]

Daniel Colascione writes:

 > I also like the idea of using pop, but you'd have to determine at
 > runtime whether you were popping from an iterator or a list, and
 > I'm not really comfortable adding that overhead.

Well, yeah, true iterators would have to be implemented at the C level
to be efficient, or you'd need to use an iterator-only function to
iterate one.  But almost 10 years of Python experience shows that
Python-style iterators and generators (especially genexps) beat pretty
much everything users actually write instead.

 > The package uses a tree walker to rewrite swaths of code into
 > continuation passing style. If you think that's sugar, I'd love to
 > see what you consider meat. :-)

I have no idea what you're talking about.  Meat isn't *sweet*,
generators are. :-)

 > Ideally, yes, and in something like Clojure, we'd be able to do
 > that with existing languages primitives --- but here, our options
 > for runtime polymorphism are limited.

Only if you restrict yourself to implementing your iterators as
"dotted lists of vectors with the last cdr being
'supercalifragilisticexpialidocious".

 > What's the alternative: a special kind of cons cell that lazily
 > generates its car and cdr?

No.  A new iterator type.  A lazy cons is an interesting idea, but
it's different and not very Lisp-y IMO (since Lisp doesn't have
laziness built in elsewhere).  (car iterator) doesn't really make
sense, to me, anyway.  Merely accessing an iterator should mutate it,
that's what it's for.

 > Providing ways to conveniently iterate over iterators (and making
 > these constructs also handle today's sequences) would be
 > sufficient.  There are only a few.

I suppose that's true, since `while' doesn't provide enough syntax to
take advantage of iterators.  But I worry more about uses which pass
an iterator accidentally to an unprepared iteration, or call it as a
function and corrupt the internal state, than about strange behavior
of a new type.  New types are expected to behave strangely!

 > I suppose it's possible to wrap the returned function in some
 > easily-distinguishable wrapper, but why would you want to?

Well, for one thing, iterating an ordinary function is an infloop
waiting to happen.

Steve