Bitten by the lambda parameter name

Alessio Stalla alessiostalla at
Wed Jul 17 03:19:05 PDT 2013

On Wed, Jul 17, 2013 at 11:47 AM, Stephen Colebourne
<scolebourne at> wrote:
> On 15 July 2013 15:52, Remi Forax <forax at> wrote:
>> This snippet not compile,
>>    Kind kind = ...
>>    partySetMap.computeIfAbsent(kind, kind -> new HashSet<>()).add(party);
>> Each time I write more than a hundred lines of codes that use some lambdas,
>> I fall into this trap.
>> It's very annoying !
> Just to note that it is correct that this not compiling. It should be
> viewed from the perspective of a code reader, not a code writer.
> There is no visible additional scope here, just an expression like any
> other. As a reader (without any further knowledge, including knowledge
> about lambdas) I'd expect that expression to have no additional scope,
> just like the ternary operator has no additional scope.
> Note that a different syntax would have affected this:
>   partySetMap.computeIfAbsent(kind, #(kind) {new HashSet<>()}).add(party);
> In this case, there is something that looks a lot more like an inner
> class and a method, in which case I'd expect the method parameter to
> have a different scope.
> The borderline case is
>   partySetMap.computeIfAbsent(kind, (kind) -> new HashSet<>()).add(party);
> where there is something that looks vaguely like a method parameter.
> But I don't think its enough to convince me that the parameter should
> be in a different scope.

I disagree, I don't think that surface syntax has anything to do with scope.
lambda x: x in Python and (lambda (x) x) in Lisp both introduce a
scope where x is lexically bound, even if their syntax differences are
quite important.

Scope is closely related to binding; does a lambda expression
introduce a binding for its parameters in its body? Yes. Then it would
be sane to scope those parameters lexically within the lambda.
Otherwise a simple refactoring (like the renaming of a lambda
parameter or even of a local variable far above!) might break
previously working code. Even JavaScript, whose scoping is quite
brain-damaged, gets this right!

That users might write bad code like foo(x, x -> x + 1, () -> x) is
not a good reason for subverting scoping rules. Users will still be
able to write code like foo(x, x2 -> x2 + 1, () -> x) which is almost
equally bad. You cannot prevent users from choosing poor variable

This is my opinion.

Some gratuitous spam: Ripple, social credit system ABCL, Common Lisp on the JVM my Lisp open source projects ManyDesigns Portofino, open source
model-driven Java web application framework

More information about the lambda-dev mailing list