question about generators

[Tim Peters]

[Tim]
> There was a lot of discussion of this at the time (dig into the
> iterators mailing list archive).  We decided to keep Simple
> Generators, well, *simple*, to start with.

[Greg Ewing]
> I don't agree with the characterisation of Python generators
> as "simpler" than Icon ones (from the user's perspective).

The characterization Simple was in contrast to continuation-based gimmicks,
not at all to Icon.  The word "generator" means something much hairier to,
e.g., Scheme-heads (e.g., you've seen Paul Rubin's recent post about
generators, which assumes a meaning for the word that isn't intended in Icon
or Python or CLU or Sather).  Simple Generators was in contrast to (Complex)
Stacklessness.

> There's a point of view from which Icon's generators are
> simpler than Python's

Absolutely.  Icon is built on generators from the ground up, so they're
natural as breathing there; they'll never be that natural in Python.

> -- that is, the one Andrew Koenig was adopting when he didn't
> immediately see the need for the "for...yield" loop.

Andrew's example "fails" in the same way if code in Icon, so this particular
example isn't helpful to your point (in Icon he would need to plop the
recursive call into an explicit "suspend" control structure to get the
example to work).

> I predicted, at the time generators were introduced, that
> some people would find this aspect of them unintuitive,
> and it seems that I was right.

Some Icon users are also suprised by this -- indeed, recursive generators
are the pons asinorum for would-be idiomatic Icon programmers too.
"Forgetting" the suspend-- and using return instead of suspend --are very
common newbie mistakes there.  However, Icon isn't any better at telepathy
than Python is, and a programmer may very well *not* wish to yield values
produced by callee generators.  In Icon and Python, you have to explicitly
"pass them up" if that's what you want (btw, in another message you seem to
assume meanings for "up" and "down" that are the reverse of most-common
usage:  IME most people seem to think of callees as returning "up" to their
callers; I'm acutely aware of this because the idea of a stack "growing
down" is repugnant to my sense of beauty too <wink>).

> If by "simple" you're referring to the *implementation*,
> then yes it would have been much harder to add Icon-style
> generators to CPython. (But only because the guts of CPython
> hadn't been designed with them in mind from the beginning
> like Icon had.)

It's more that the *semantics* of Python weren't designed with generators in
mind at all.  Icon-style generators with a wholly Icon flavor would be a
poor fit to Python.  I call what we implemented in Python "resumable
functions", because that's still the best conceptual fit to Python's
semantics.  Implementation ease and ease of fitting into Python's semantic
model are usually strongly related, perhaps because Guido has always favored
operational definitions.