Re: Accumulator

[address@hidden (Jeremy Hylton)]

[I'm a bit behind on this thread.  No messages on the list for months,
then I go on a one-week vacation and receive 250 messages. :-)]

>>>>> "PP" == Paul Prescod <paul@prescod.net> writes:

  PP> Avi Bryant wrote:
  >> Just to clarify - what I think you mean is that anything that can
  >> be done with *Python's limited form of lambda* can be done
  >> without it, since inner functions have the same restrictions
  >> lambda does.

  PP> Inner functions have less restrictions than lambda, but the
  PP> particular restriction about overwriting variables from outer
  PP> scopes is still in effect. I still maintain that this encourages
  PP> a better (OO, in an OO programming language) style of
  PP> programming. It seems strange to me that it is hard to get
  PP> people to agree that Python's choice might just be better for
  PP> Python programmers.

It's not at all clear to me that Python's current semantics are better
than a variant that allowed rebinding of names in enclosing scopes.
The PEP [a PEP is roughly equivalent to a SRFI]	describing nested
scopes says:

    There are technical issues that make it difficult to support
    rebinding of names in enclosing scopes, but the primary reason
    that it is not allowed in the current proposal is that Guido is
    opposed to it.  His motivation: it is difficult to support,
    because it would require a new mechanism that would allow the
    programmer to specify that an assignment in a block is supposed to
    rebind the name in an enclosing block; presumably a keyword or
    special syntax (x := 3) would make this possible.  Given that this
    would encourage the use of local variables to hold state that is
    better stored in a class instance, it's not worth adding new
    syntax to make this possible (in Guido's opinion).

There are a bunch of subtle interactions that make PG's example hard
to code in Python.  The lack of declarations other than the global
statement make it impossible to specify where an assignment should be
to a local or to a free variable bound in an enclosing scope.  I
had hoped to solve this problem when I implemented nested scopes, but
there wasn't time and Guido disagreed on its utility.

Before Python had nested lexical scopes, there was a lot of
disagreement about whether it was a useful feature.  Now that they are
supported, the overall reaction seems favorable; certainly my
co-workers use them a lot.  I can't help but think that full support,
including rebiding, would have played out much the same way.

The dichotomy between expressions and statements is equally
troublesome.  There's no obvious way to substitute a statement for an
expression or include a statement within an expression.  This is a
problem for the accumulator example, this is the problem; assignment
is a statement and lambda is an expression.

Jeremy