Iterators in Sather and Python (was Re: Result of I need your experience - classification and comparison of languages)

Alex Martelli aleax at aleax.it
Mon May 13 13:09:54 EDT 2002


Terry Reedy wrote:
        ...
>>  Traversing more than one structure at a time is easy for Sather,
> not for Ruby.
> 
> Python, of course, has map and zip and proposals (accepted yet?) for
> lazy, iterator/generator oriented versions.

Not accepted yet, but explicit calls to .next() will allow multiple
traversals more flexibly, anyway:-).


>> Sather's iterators are _way_ more powerful than Python's because
>> Sather's can accept both "hot" arguments (evaluated anew each time
>> the iterator is called) and "once" ones (evaluated only at the first
>> call on the iterator).
> 
> Python generators can be called with mutable arguments, can they not?

This has little to do with the power of "hot arguments" to Sather 
iterators, which are simply general expressions evaluated afresh each 
time the iterator is called, while a "once argument" is evaluated at
the first call to the iterator within a given loop statement.


> uniformity and variety have advantages as others have discussed.  If a
> language has non-function statement syntax like 'loop ... end' and 'if
> ... then ...', then I prefer that control items like while, until, and
> break be part of that statement syntax.  I (and others) see while as a
> multiple-execution version of if.  On the other hand, resumable

This is our most substantial disagreement -- I consider the unification
of ALL loop control structures into one overarching concept to be the
main contribution of Sather to innovation in programming languages.  No
reason to have all sort of different syntax when ONE syntax and one
Big Idea does it all (and more) even better.  Sure, you COULD express
"loop if!(condition) ... end" (although the semantics of this very
hypothetical "if!" iterator would have to be 'bundled').  But the
parallel between while and if is quite imperfect in most languages,
anyway.  Python does have while/else, but it stretches things a bit
to consider its semantics "a multiple-execution version" of those of
if/else -- and no while/elwhile/elwhile/else parallel to if/elif/elif/else
is on offer anyway.  Should it?  I don't think so.  Sather's loop/end
and iterators is a just much nicer way to generalize loops, and I don't
think it makes sense to reject it based on a hypothetical parallelism
between while and if that doesn't hold anyway!


Alex


> consumers are in general as sensible as resumable producers.  It is
> Python's for-loops which make the latter more special for Python.
> 
> Terry J. Reedy




More information about the Python-list mailing list