Let's Talk About Lambda Functions!

[Alex Martelli]

Paul Rubin wrote:

> Alex Martelli <aleax at aleax.it> writes:
>> It's not an issue of syntax sugar as superficial as what keyword to
>> use.  A REAL lambda, by any other name -- the ability to package up
>> ANY chunk of code, not just an expression -- might add power enough
>> to justify its existence.  Today's lambda's just deadweight.
> 
> I agree that the current incarnation of lambda is deficient.  I

Great -- we do have one point of agreement.  I fear it will be
the only one:-).

> think it should be strengthened so you can lambdafy arbitrary code,

So, invent a syntax that is nice, Pythonic (indentation etc), and
free of ambiguity and error-prone aspects.  Me, I haven't managed
to, but that doesn't say much.  It MAY be more significant that no
such wonderful syntax has ever been proposed (that I know of)
throughout the interminable debates over the years about lambda,
anonymous codeblocks, and other such themes.

> not eliminated.  The current version is better than nothing, though.

Here's where we disagree.  It adds no real ability to the language,
just little traps, pitfalls, annoyances and MTOWTDIs.


> I don't see why the anti-lambda contingent doesn't want to also
> get rid of anonymous scalar expressions.  I mean,

"scalar"?  What's "scalar" about it?

>    a = b + (c * d)

This could perfectly well be a list expression -- concatenate
list b with c repetitions of list d (or, d repetitions of list
c).  "scalar"...???

The parentheses above are redundant, of course.  That may make
using them bad style, but allowing them in terms of language _rules_
is one of those MTOWTDIs we can never eliminate without ADDING
horrible complications to the syntax.

Hypothetically removing the production for lambda from the
syntax would of course, just as hypothetically, simplify the
syntax.  Removing the ability to parenthesize EXCEPT where
the parentheses are significant would be a nightmare of
complexity for no real gain.

It's therefore rather silly to try to equate the two things.

> the horror!  Why not insist on naming the subexpressions, e.g.
> 
>    temp = c * d
>    a = b + temp

If there is further significant use of that c*d result later
on, giving it a name (though not one such as 'temp', most
likely, unless it's something's temperature I guess) might
be a good idea.  If the intermediate result is insignificant
per se, then naming it would have no added value.

It's rarely the case that functions are insignificant.  The
DO something, or COMPUTE something, which tends to make them
worth naming.  A result of a multiplication, on the other hand,
IS something, and the verb "to be" is fraught with problems
(I summarize some of them, albeit in a different context, in
http://www.aleax.it/Python/5ep.html -- most significant are
the bibliographical pointers to the relevant works of 
Santayana, Wittgenstein, and most relevantly Korzybski).

Summarizing: it's seldom the case that it's optimal to draw
attention to what something IS.  It's often the case that it's
best to draw attention to what something DOES.  Thus, naming
intermediate results that "just ARE" (results of such ops as
adding, multiplying, ...) is only interesting in quite specific
cases, basically when the thing you're naming has some domain
specific relevance.  Naming objects that "DO", i.e., functions,
is more often advisable.

If in one case in a thousand there's some slight advantage
to not-naming a doer, that doesn't mean lambda is pulling
its weight -- it's still deadwood, not worth the downsides.


Alex