PEP 276 Simple Iterator for ints (fwd)

[David Eppstein]

In article <9uomtp$e1cbj$1 at fido.engr.sgi.com>, pj at sgi.com (Paul Jackson) 
wrote:

> Ah - you may have exposed my primary concern with this - thanks.
> 
> It isn't obvious to me which variables are free and which bound.

Why do you think it's obvious which is bound and which unbound
with the "for i in L" syntax, in situations where both i and L are 
variables?  I think it's a matter of what you're used to.  In expressions 
like "element in member" the bound variable is always the first one, in 
expressions like "lb < i <= ub" the bound variable is always the middle one.

But anyway, it would also be acceptable to me to use a syntax like
"for i in lb < ... <= ub". This would also answer the other common 
objection that all for-loops must use "for var in iterator" syntax.
I prefer the other syntax, because I think this one is verbose in a way 
that doesn't actually improve readability (verbosity that improves 
readability is better than conciseness, though).

> All the examples I happened to read earlier in this thread had
> only one variable, and used explicit integer constants for the
> bounds, as in:
> 
>     for 0 <= x < 5:
> 
> In that case, it's pretty obvious that 'x' is the free variable.
> 
> But in your notes, you have things such as:
> 
>     for n > i >= 0:
>         for i < j <= n:

I believe this matches the standard mathematics conventions e.g. for 
subscripts of summation signs.

> Here it seems to rely on some assumption that the middle
> term, i or j, is the free variable.  So at least the
> following two variants:
> 
>     for 0 <= x**2 < 16:               # integers x whose square is in range(16)
>     for 0 <= x:                       # non-negative integers x
> 
> should not be allowed, because they violate the assumption I
> just surmised.  Or then the assumption gets more subtle.

They should not be allowed unless "for x**2 in L" is also allowed.

> Pseudo code, such as in David's lecture notes, has the advantage
> that it can rely on contectual comments, suggestive variable
> names, and the authors descretion to avoid non-trivial cases.
> But programming language syntax needs to be parsable by clear
> rules, even absent (1) comments, (2) suggestive variable names,
> or (3) discrete authors.

The clear rule is, the middle term of a three-way comparison is always a 
variable, just like the way (in current Python) the left term of an "in" 
expression is always a variable.
-- 
David Eppstein       UC Irvine Dept. of Information & Computer Science
eppstein at ics.uci.edu http://www.ics.uci.edu/~eppstein/