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

[Terry Reedy]

"Alex Martelli" <aleax at aleax.it> wrote in message
news:CrSD8.52710$zW3.722063 at news1.tin.it...
> Terry Reedy wrote:
> > 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.

The point I was making is that one *could* pass fresh values to a
generator at every iteration via a list or dict and have the same
effect as the Sather method.  I don't recommend this, but I also think
it is at least a bit wierd to have function calls that don't do what
they look like they are doing and which might do something different
after the first call.  If I understand correctly, in the Sather
version of the following:

from somewhere import it
a = b = 1
while 1:
  f(it(a,b))
  a = a+1
  b = b+2

one cannot tell from looking at the above whether either of the last
two lines has any affect. Depending of the parameter-list definition
in the it() source, it(a,b) could mean any of  it(1,1), it(1,b),
it(a,1), or it(a,b).

...
>This is our most substantial disagreement

Yes

> -- 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.

It is a matter of where you draw the line between what to unify and
what to treat differently.  In this case, the question is whether
'iterative flow-control' should be unified with 'alternative
flow-control'  or 'iterative collection-access'.

>  No reason to have all sort of different syntax when ONE syntax and
one
>Big Idea does it all (and more) even better

Which is why some people like Lisp.  On the other hand, some people
prefer mixing operator expressions, function calls, and statements,
even if they do understand the unifying Big Idea of function
composition.

> But the  parallel between while and if is quite imperfect in most
languages,
...
> I don't think it makes sense to reject it based on a hypothetical
parallelism
> between while and if that doesn't hold anyway!

'while condition: block' is syntactic sugar for ':label: if condition:
block; goto label'.

My view was partly formed by Dijkstra's guarded command notation as
used, for instance, in The Science of Programming by David Gries.  He
used two flow control commands: one for alternation and one for
iteration.  With '[] condition->block' changed to its Pythonic form,
they are:

if
    condition1: block1
    condition2: block2
    ...
    conditionn: blockn
fi

do
    condition1: block1
    condition2: block2
    ...
    conditionn: blockn
od

The difference for 'do' is the addition of an implicit 'goto enclosing
do' at the end of each block.

Terry J. Reedy