From the beat-that-dead-horse department: I've never really been
satisfied with the outcome of the discussion on lambda and anonymous
functions.
As much as I love the use of syntactic indentation in Python, it does
have one serious drawback, which is that it creates a wall between the
realms of 'statements' and 'expressions'. Statements are delimited by
line breaks (generally), while expressions are free-format. The result
is that while statements can contain expressions, expressions cannot
contain statements.
None of the scripting languages which are direct competitors to Python
(in particular, Ruby, Javascript, Perl, Lua, etc.) have this limitation,
and all of them are able to take very powerful advantage of the ability
to freely mix statements within expressions.
Javascript, for example, doesn't need special syntactical sugar for
generator expressions:
/* Return a list of the square of numbers.
('map' appears courtesy of Mochikit.js) */
result = map( [1, 2, 3, 4], function (a) {
return a * a;
})
No, its not quite as concise as a generator expression, but it is far
more general in what it can do.
Now, there are those who say "Just use a named function", but that
argument doesn't hold - because the *same* argument can be levied
against generator expressions, the 'with' statement, and a number of
other recent syntactical innovations in Python.
From my point of view, both 'with' and generator expressions are
limited, special-case solutions to a general problem - the desire to be
able to use and manipulate unnamed blocks of code as first-class
objects. Conversely, the same arguments that make 'with' important
enough to change Python syntax - instead of just saying 'use a named
function' - apply here as well, only in this case we're not talking
about a specific use case, but rather a whole class of use cases which
has yet to be fully explored.
There are also those who would claim that, given the lack of use of
'lambda' in existing Python code, that there's no compelling use case.
To this, I have two counter-arguments:
1) This is IMHO a chicken-and-egg problem. Anonymous functions aren't a
solution to an existing problem, so much as they are an opportunity to
explore new kinds of solutions to new kinds of problems in Python. As
long as functions must be named (or crippled, as in the case of Lambda),
people are going to find workarounds.
2) Many of those 'workarounds' are going to come back in the form of
PEPs to add new language features. I predict that we'll see a
never-ending parade of enhancement proposals - lazy evaluation
expressions, asynchronous callback expressions, and so on - all of which
are in a sense compensating for the lack of the ability to treat code
like data.
Instead of attempting to address the problem piecemeal, and thereby
obfuscating the clean, elegant minimalism of Python (more than it
already has been), I say we cut to the chase and deal with the root problem.
Of course, I realize that this isn't an easy problem to solve - its
inherent in Python's syntax choices, and certainly I don't want to give
those up. But I want to specifically argue against the idea that "it's
hard to solve, and it's not important, so let's not bother with it". My
argument is that it may be hard, but it *is* important.
I'm going to refrain from adding any hare-brained syntax proposals of my
own here - I'm more interested in trying to convince people that this is
a problem worth bothering with.
I would like, however, to be clear in defining the parameters of the
problem I would like to see addressed. I am not arguing *specifically*
for anonymous functions of the 'lambda' type, although that would be one
possible solution to the problem. What I want is "the ability to treat
anonymous code blocks as first-class objects", which is a larger space
of solutions than just lambda functions. For example, a solution that
didn't involve parameter binding would not be a lambda function, but
would still meet my criteria.
-- Talin
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
