On Fri, 03 Jun 2011 11:43:54 +1200, Gregory Ewing wrote:
>> But going against generally accepted semantics should at least
>> be clearly indicated. Lambda is one of the oldest computing abstraction,
>> and they are at the core of any functional programming language.
>
> Yes, and Python's lambdas behave exactly the *same* way as
> every other language's lambdas in this area. Changing it to
> do early binding would be "going against generally accepted
> semantics".
In Lisp, it depends upon whether the free variable is bound:
$ clisp
[1]> (setq f (lambda (x) (+ x i)))
#<FUNCTION :LAMBDA (X) (+ X I)>
[2]> (setq i 7)
7
[3]> (apply f (list 4))
11
[4]> (setq i 12)
12
[5]> (apply f (list 4))
16
^D
$ clisp
[1]> (let ((i 7)) (setq f (lambda (x) (+ x i))))
#<FUNCTION :LAMBDA (X) (+ X I)>
[2]> (apply f (list 4))
11
[3]> (setq i 12)
12
[4]> (apply f (list 4))
11
^D
If the variable is bound, then the lambda creates a closure.
And Python behaves the same way:
> f = (lambda i: lambda x: x + i)(7)
> f(4)
11
> i = 12
> f(4)
11
# If you really want a "let", this syntax is closer:
# f = (lambda i = 7: lambda x: x + i)()
The original semantics (from the lambda calculus) don't deal with the
concept of mutable state.
> If anything should be changed here, it's the for-loop, not lambda.
Right. The for loop should bind the variable rather than set it.
--
http://mail.python.org/mailman/listinfo/python-list
