Well, this whole thread started with a quite concrete problem - my
collect() function. Since the first version - the one that used 'for'
instead of 'map' and 'lambda' WORKED, clearly, one clean and simple
solution, would be just to get rid of lambda - since it is
unnecessary, limited and error prone. ( But since I LIKE lispish
features like lambda,map,etc., I was not inclined to propose that
solution until YOU brought it up. But I would have to admit that
that WOULD be a consistant solution. )
[ But yes: in an effort to avoid endorsing either the CSNS solution,
or the above solution, I was groping around with a lot of loosely
knit ideas. Maybe it's time to give it a rest. ]
> One of the first good papers to seriously question the value of classical
> nested scopes is Dave Hanson's "Is Block Structure Necessary?" (Software
> Practice & Experience, Vol 11, pp 853-866, 1981). He argues that CSNS
> creates at least as many problems as it solves, that simple non-nested
> modules solve the same problems without CSNS's drawbacks, and illustrates
> with non-trivial programs written idiomatically in both styles.
Thanks for the reference. I'll take a look at it.
However, considering your comments about the mistakes everyone
usually makes until they read and understand the reference manual
chapter on scoping, and question 4.5 of the FAQ, there may be
grounds for arguing that python's scoping rules ALSO create as
many problems as they solve.
One of the reasons that Static Scoping is considered a Good Thing,
is that it increases the capability to understand code from local
textual information and requires less global information. This
was what I meant when I said that Python's scoping, in that case,
didn't *LOOK* as if it was static. Of course, it *IS* static
scoping, but in that case, the result is an instance where one
has to understand that what looks like a local expression is
actually evaluated in a quite different context from the one
in which it appears. The mechanics are quite different, but
otherwise, that's just the sort of non-local effect that static
scoping was supposed to avoid! After all - IF you understand the
scoping rules and the way expressions are evaluated, dynamic scoping
can be understood. You just have to remember that expressions may not
mean LITERALLY what they APPEAR to mean - you have to consider the
context in which they will be evaluated ... which seems to be
pretty much what you're telling me about Python's static scoping.
OK - there is one exaggeration in the above: dynamic scope can be
much more difficult to analyze. But the point is that you have to
stop and analyze it, you can't just read the code and expect that
the "n" on line 7 has the same value as the "n" on line 6.
[ Come to think of it, INTERCAL has such a feature. But INTERCAL
was also the language that improved on the GOTO by introducing
the COME-FROM statement. ]
-a-little-more-pevishly-that-usually,
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics