What can you do in LISP that you can't do in Python

[Alex Martelli]

"Darren New" <dnew at san.rr.com> wrote in message
news:3B0AA198.9240FBD3 at san.rr.com...
> Alex Martelli wrote:
> > but unevaluated code, with parameters.  And the only, let's
> > say, "limitation", compared to lambda, is that you have to
> > give the function a _name_.  That's a pretty modest limitation:-).
>
> Nope. You have to give it a name *and* you have to write it somewhere
> outside of the statement (and maybe function) that's using it. I.e.,

Statement, yes -- def is a statement so can't nest 'inside' the use.
But *WHY* should the def be outside the function using it?!  Put
it right before the use, for Pete's sake... why not?!

> you've violated the style of both OO and structured programming.

How does splitting a statement into two "violate the style of both
OO and structured programming"?!  It's COMMONLY DONE in OO
(_and_ sp).

For example, say I have a stack-type with a .pop() method that
removes the stack top AND returns it -- like a Python list.  So
'add the two entries on the top of the stack' is one statement:
    value = stk.pop() + stk.pop()

But suppose some language, let's make up a fantasy name, oh,
"Eiffel", decides that having functions that both return a result
AND have side effects is bad.  Does that violate OO?  Boy I'd like
to see you and Meyer duking it out on the ring, given how much
he presents himself as the Prophet of OO...!

So we have a .top() function that returns the stack top, and a
separate .pop() procedure (can't be called inside the same
expression) that returns nothing and has the side effect.  So:
    value = stk.top()
    stk.pop()
    value += stk.top()
    stk.pop()
Wordier, sure, but *WHAT PRINCIPLES DOES IT VIOLATE*?!

Cheez... as it happens, the C++ Standard Library has adopted
a similar architecture (not for "a priori" reasons like Meyer's,
but there IS a serious problem in the combined-effects choice
*in a language where assignment can raise exceptions* -- it's
explained well in Sutter's "Exceptional C++" book, for example).

I claim that splitting a statement into more than one because
a language doesn't merge the concepts of expression and
statement, doesn't let a value-returning function also have
side effects, doesn't let assignment have a value usable as
a part of an expression, etc, etc, violates NO principle though
in some cases it may marginally reduce convenience, as in the
above stack example.

And I consider the step from:
    return map(lambda x: x+1, myseq)
to, say:
    def increment(x): return x+1
    return map(increment, myseq)
to be exactly comparable with the above 'split', and similarly
violate no principles (at least, no SANE ones!-).


> Now you need to give it a doc string,

Not by Pythons' rules, you don't.  If you program in a different
language that add "needs" which Python doesn't have, that's
the fault of your chosen language, NOT Python's.

> pass in the arguments that would
> normally be in scope in a language designed to work with such blocks,

You mean, like Python 2.2 (or 2.1 with suitable 'from')...?  This
is totally orthogonal to the "lambda vs named-function" issue,
anyway -- scopes nest for both or neither kind of function.

> etc.

Please spell out this 'et caetera', because there are no other
issues (actually, the ones you MENTIONED aren't issues
either, so, on second thoughts, don't bother:-).


> It's not just making up a name, after all.

Right -- in addition to making up a name, there is the bigger
task of fighting prejudice and disinformation, such as that
nicely false assertion up there that splitting a statement
into two "violates style" &c ("maybe function" INDEED...!).

But then, apparently, such a fight is inevitable any time one
talks common sense, so it's not specific to passing a local
named function... to avoid the fight, if by absurd it were
possible, one would have to program in such a crazy and
contorted style as to make it not worth the bother... put all
in one statement to avoid fighting with Mr New, AND have
no side effects in value-returning functions to avoid duking
it out with Dr Meyer, AND ....

Nah, the fight IS inevitable, so it would be unfair to debit
it to the account of named-local-function passing!-)


Alex