Iterators & generators (RE: Real Problems with Python)

[Tim Peters]

[Tim sez of Aahz]
> [Aahz Maruch, proves that you don't have to be a lambda-head to
> pick up the thrust of it at once -- thanks!]

[and Aahz sez]
> I have to admit that I used Icon briefly in a CS class more than a
> decade ago; it made much more of an impression on me than Lisp did,
> even though I still have my LISPcraft book and I can't seem to find
> my Icon book.  (My professor was from UoA.)  It was interesting
> trying to cast my memory back that far.

So it *stuck* across a decade, anyway, despite brief exposure.  That's a
good sign!  Python isn't as concerned about things that are obvious at first
glance, as about things that you don't forget once mastered (e.g., "points
*between* elements" indices).  The Icon book is now on its 3rd edition, BTW,
and you should treat yourself to a copy <wink -- but it's among the best
intro language  books ever>.

> BTW, it turns out that much of the Icon documentation is now
> on-line at
> http://www.cs.arizona.edu/icon/

Along with free distributions & source code, for people who don't know that
Icon is one of the oldest Open Source languages going (actually, Icon is
public domain -- *you* can claim the copyright <wink>).

> From my POV, Icon is a lot like Perl written by a Pascal programmer,
> with (from my more experienced viewpoint) its almost excessive emphasis
> on expressions rather than statements.

Bad Icon can make bad Perl look crystal clear, athough the Icon community is
good about being as clear as possible.  Unfortunately, when "success" and
"silent failure" are fundamental notions applying to every little
expression, even in exemplary Icon it can be very difficult to figure out
whether a particular potential for failure is being ignored by mistake or
design.  So while it's brilliantly innovative in many respects, in practice
I found I coudn't keep larger Icon programs working under modification.
It's still my first language of choice for tackling several kinds of complex
one-shot "researchy" problems, though.

> I think that overall Python doesn't go quite far enough in that
> direction,

I agree, but it's gotten "better" this way, mostly via little things like
the addition of dict.get() and 3-argument getattr -- not everything is
better spelled on 4 lines <wink>.  Stroustrup has written that he would like
C++ to treat everything as an expression too, so that e.g. even loops could
be rvalues (as they can be in Icon -- and, irritatingly, sometimes are).  If
Guido had to err here, I think he picked the right side.

> but adding generators should make up much of the balance.

Unsure it would help here, at least in the flavor I've been selling them.
*Everything* in Icon is "a generator", even the integer 42 (it generates a
singleton sequence, in theory), so the concept is fundamental & pervasive in
Icon.  More fundamental even than success and failure ("failure" is simply
an empty result sequence, and "success" non-empty).

That doesn't fit with Python at all, so I'm just trying to get the most
useful & conventional & well-behaved part:  explicit generation when you ask
for it, at the function level.  That would add enormous bang for the buck,
and greatly aid clarity when appropriately used.  So that much is Pythonic
to the core.

after-a-decade-i'm-still-trying-to-get-guido-to-understand-
    what-python-is<wink>-ly y'rs  - tim