Comments on: Python’s lambda is broken!

By: Andrej Bauer

Andrej Bauer — Sun, 23 May 2010 05:18:12 +0000

@Evan: your argument can be applied to other constructs as well. In Python we do not really need dictionaries because they can be replaced by association lists. I can tell you from personal experience that dictionaries are far more confusing for students than lists. This line of reasoning does not work very well. But yes, a language needs a balanced set of features.

The question is whether lambda belongs to such a set. There are many reasons why the answer is positive. For example, lambda abstraction is one part of a fundamental mathematical concept, namely that of a function, the other part being application (of a function to an argument). It seems clear to me that such a primitive concept can be useful and probably should be part of a language.

If we designed languages according to what “production environment workers” can comprehend, we’d still be hunting with sticks and stones.

By: Evan

Evan — Sun, 23 May 2010 00:59:13 +0000

If a lambda function can be converted to work as a non-lambda function with little effort, why add the unnecessary complexity.

It’s pretty obvious, that from a practical standpoint, most people can’t inherently grasp the idiosyncrasies of lambda expressions. Otherwise, you wouldn’t have so many comments on this thread explaining what it tries to accomplish.

I think, GvR has a pretty good understanding that his language is used extensively in production environments (not just academic); and, adding features for features sake is a mistake.

If you want a dynamically-typed, light-weight, functional programming language that supports useless constructs like lambda expressions why don’t you write your own. Wait, there are already 11 different dialects of Lisp.

Don’t forget, some of us actually use python to produce code to make money.

By: Edvard Karlsen

Edvard Karlsen — Tue, 11 May 2010 17:35:58 +0000

I don’t see the big problem here. Obviously, it’s a bit confusing, but as others have stated, this is often the way closures are implemented in modern multi-paradigm languages. In my opinion, this behaviour should be expected in this language with so much mutable state. Anyway, the problem here is not that the lambdas capture values, but how the for loop works.

However, to repeat earlier posters, there are other solutions.

>>> a = lambda n: lambda nn: n + nn >>> a(3)(5) 8

Starting with this approach is imho more flexible, clearer, reads better and possibly more memory efficient. If one then should need/want a list of a specific lambdas of this form, one could do so with classic list comprehension as suggested earlier. Stuff like “i=i” etc. are hacks that can easily be avoided :)

By: VaporWarning» Blog Archive » Notes from the JS pit: closure optimization

Tue, 11 May 2010 10:01:40 +0000

[...] closure-by-reference can produce side effects that surprise developers, such as: def surprise(): funs = [lambda: x ** 2 for x in range(6)] assert [...]

By: joseanpg

joseanpg — Tue, 09 Jun 2009 19:25:49 +0000

En Scheme la semántica básica de las capturas es la misma que en Python y JavaScript

(define (ruma)
(let ((k 10)(fs ‘()))
(define (r)
(if (= k 1)
fs
((lambda ()
(set! k (- k 1 ))
(set! fs (cons (lambda () write k) fs))
(r)
))
)
)
(r)
)
)

Todas las funciones de la lista devuelta por esta función nos dan el valor 1, el último valor que toma k. Esto implica que las clausuras de la lista capturan la referencia a k, no su valor.