[Python-Dev] lambda in Python

[xahlee]

Today i ran into one of Guido van Rossum's blog article titled  
“Language Design Is Not Just Solving Puzzles” at
http://www.artima.com/weblogs/viewpost.jsp?thread=147358

The article reads very kooky. The bottom line is that Guido simply  
does not like the solution proposed for fixing the lambda construct  
in Python, and for whatever reasons thinks that no solution would  
satisfy him about this. But instead, he went thru sophistry on the  
ignorance and psychology of coder mass in the industry, with mentions  
of the mysterious Zen, the cool Google, the Right Brain, Rube  
Goldberg contraption irrelevancies.

 From his article, i noticed that there's largish thread of  
discussions on lambda.
The following is a essay i wrote after reading another one of Guido  
blog, in which shows prejudice and ignorance about functional  
programing. I hope it can reduce the ignorance about lambda and  
functional programing.

--------------------------
Lambda in Python 3000

Xah Lee, 20050930

On Guido van Rossum's website:
http://www.artima.com/weblogs/viewpost.jsp?thread=98196 (local copy)
dated 20050310, he muses with the idea that he would like to remove  
lambda, reduce(), filter() and map() constructs in a future version  
Python 3000.

Guido wrote:

     «filter(P, S) is almost always written clearer as [x for x in S  
if P(x)], and this has the huge advantage that the most common usages  
involve predicates that are comparisons, e.g. x==42, and defining a  
lambda for that just requires much more effort for the reader (plus  
the lambda is slower than the list comprehension)»

The form “[x for x in S if P(x)]” is certainly not more clear  
than “filter(P, S)”. The latter is clearly a function, what is the  
former? A function every programer in any language can understand and  
appreciate its form and function. Why would anyone to expect everyone  
to appreciate a Python syntactical idiosyncrasy “[x for ...]”?

Also, the argument that the form “filter(F,S)” being cumbersome  
because the first argument is a function and that mostly likely it  
would be a function that returns true/false thus most people will  
probably use the inline “lambda” construct and that is quite  
cumbersome than if the whole thing is written with the syntactical  
idiosyncrasy “[x for ...]”, is rather inane, as you can now see.

The filter(decision_function,list) form is clean, concise, and helps  
thinking. Why it helps thinking? Because it condenses the whole  
operation into its mathematical essence with the most clarity. That  
is, it filters, of a list, and by a yes/no decision function. Nothing  
is more, and nothing can be less. It is unfortunate that we have the  
jargon Lambda and Predicate developed by the tech geekers of the  
functional programing community. The lambda could be renamed Pure  
Function and the Predicate could be called True/False function, but  
the world of things being the way they are already, it is unwise to  
rewrite every existing Perl program just because somebody invented  
another language.

If the predicate P in filter(P,S) is cumbersome, so would exactly the  
same thing appear in the syntactical idiosyncrasy: “[x for x in S if  
P(x)]”.

Guido added this sting as a afterthought:

     «(plus the lambda is slower than the list comprehension)»

Which is faster is really the whim and capacity of Python compiler  
implementators. And, weren't we using clarity as the judgement a  
moment ago? The concept of a function every programer understands,  
but what the heck is a List Comprehension? Why don't you scrap list  
comprehension in Python 3000 and create a table() function that's  
simpler in syntax and more powerful in semantics? ( See http:// 
xahlee.org/perl-python/list_comprehension.html )

     «Why drop lambda? Most Python users are unfamiliar with Lisp or  
Scheme, so the name is confusing; also, there is a widespread  
misunderstanding that lambda can do things that a nested function  
can't -- I still recall Laura Creighton's Aha!-erlebnis after I  
showed her there was no difference! Even with a better name, I think  
having the two choices side-by-side just requires programmers to  
think about making a choice that's irrelevant for their program; not  
having the choice streamlines the thought process. Also, once map(),  
filter() and reduce() are gone, there aren't a whole lot of places  
where you really need to write very short local functions; Tkinter  
callbacks come to mind, but I find that more often than not the  
callbacks should be methods of some state-carrying object anyway (the  
exception being toy programs).»

In the outset Guido here assumes a moronitude about the set of Python  
users and what they are familiar of. Python users 10 years ago are  
not the same Python users today, and will certainly not be the same  
10 years later if you chop off lambda. Things change, math literacy  
advances, and what users you have changes with what you are. A  
function is the gist of a mathematical idea embodied in computer  
languages, not something from LISP or Scheme as tech geekers wont to  
think.

     «... there is a widespread misunderstanding that lambda can do  
things that a nested function can't...»

One is so insulted by a industrial big shot in quoting something so  
disparate then shot it down as if showing his perspicacity.

A lambda is a syntax for function or a name for the concept of  
function. What does it mean that a lambda isn't as powerful as nested  
function??

The lambda in Python is really ill. It is designed with a built-in  
limitation in the first place, and regarded as some foreign substance  
in the Imperative Crowd such as the Pythoners. If there's any problem  
with lambda, it is with lambda in Python and Pythoner's attitude.

     «Also, once map(), filter() and reduce() are gone, there aren't  
a whole lot of places where you really need to write very short local  
functions;»

Of course, one begins to write things like Java: in three thousand  
words just to show you are a moron.

The removing of elements in a language is in general not a good idea.  
Removing powerful features so that coding monkeys can use it is  
moronic. (e.g. Java) Removing “redundant” constructs is not always  
smart (e.g. Scheme), because it pinches on practicality. Removing  
existing language features by a visionary upgrade is a waste. It  
forces unnecessary shakeup and can cause death.

     «So now reduce(). This is actually the one I've always hated  
most, because, apart from a few examples involving + or *, almost  
every time I see a reduce() call with a non-trivial function  
argument, I need to grab pen and paper to diagram what's actually  
being fed into that function before I understand what the reduce() is  
supposed to do. So in my mind, the applicability of reduce() is  
pretty much limited to associative operators, and in all other cases  
it's better to write out the accumulation loop explicitly.»

The existence of reduce() in Python is probably caused by tech  
geeking clowns of the computing industry. Basically, nobody really  
have a clear understanding of mathematics or computing semantics, but  
every elite tech geeker knew one bag of constructs of various  
languages. So, you add this, i want that, and the language becomes a  
incoherent soup of constructs, with the backlash of wanting to chop  
off things again, with that good things.

reduce() in fact embodies a form of iteration/recursion on lists,  
very suitable in a functional language environment. If Python's  
lambda and other functional facilities are more powerful or complete,  
reduce() would be a good addition. For instance, in functional  
programing, it is a paradigm to nest or sequence functions. (most  
readers will be familiar in the form of unix shell's “pipe”). When  
you sequence functions, you can't stop in the middle and do a loop  
construct. So, reduce() and other functional forms of iteration are  
convenient and necessary.

Suggestions: lambda, reduce(), filter() and map() all should stay.  
I'm not sure exactly what's the ins and outs of Python 3000. If one  
wants to shake things up based on a vision: don't. There are already  
gazillion languages and visions; the world really don't need another  
bigshot's say for their personal advancement. As for improvement,  
lambda in Python should be expanded to remove its built-in limitation  
(and Imperative Programing Crowd such as Pythoners should cease and  
desist with their lambda attitude problem). The function map() could  
also be considered for expansion. (see “What is Expressiveness in a  
Computer Language” at http://xahlee.org/perl-python/ 
what_is_expresiveness.html ) Function reduce() should stay because  
it's already there, even if it is not very useful and odd in Python.  
filter() should stay as it is as it is superb and proper.

...

the rest of the article explaining the functions of the functions in  
question is at:
http://xahlee.org/perl-python/python_3000.html

    Xah
    xah at xahlee.org
∑ http://xahlee.org/



☄