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

[Darren New]

Alex Martelli wrote:
> 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?!

Err, so if it's inside a loop, you're running the "def" each time thru
the loop? Or does Python take care of that for you, and only run the def
statement once?

I'd actually forgotten you can def functions inside other functions.

> > 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).

No. Moving code that's private to a function outside that function
violates information hiding and such. Moving code that's logically part
of a loop to outside the loop simply because the language requires it be
in a different place is bad for structured programming.

Having to name bits of code just so you can pass them to other routines
is about as annoying (in my experience) as having to declare stuff in
the order it's used so the compiler can make one pass thru the code.
Nothing major, but not completely trivial either.

I think you're taking this way too seriously, and perhaps you should
consider decaf. ;-) The irrelevant analogies that fail to be analogous
are hence snipped.

> 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...!).

Oh come on. I'm merely comparing python's convenience to smalltalk's
convenience w.r.t. unnamed functions. The lack of nested scopes and the
requirement to name every block of code that gets passed around makes it
more difficult.

Why not require every statement that needs a block of code to use a
function too? Then you could get rid of "break" entirely.

def true_part_one(): ...
def false_part_one(): ...
...
if (x < 0): true_part_one
else: false_part_one

Exagerated, of course, but not unlike dartmouth BASIC. I was just
disagreeing that the need to give it a name is as trivial as you thought
it is, that's all.

> 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!-)

Man, you really do have a wild hair, don't you?

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
       San Diego, CA, USA (PST).  Cryptokeys on demand.
     This is top-quality raw fish, the Rolls-Rice of Sushi!