Something is rotten in Denmark...

[Nobody]

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.