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

[James_Althoff at i2.com]

Alex Martelli writes:

>The equivalent of your Smalltalk example:
>
>    object ifTrue: [ block of code to be evaluated ]
>   ifFalse: [ block of code to be evaluated ]
>
>would therefore need rather-different syntax sugar, e.g:
>
>    def ifTrue():
>        # one block of code to be evaluated
>    def ifFalse():
>        # another block to be evaluated
>    object(ifTrue=ifTrue, ifFalse=ifFalse)
>
>assuming the object's __call__() method is the one that
>performs the true/false selection.

For those interested: in Smalltalk "ifTrue/ifFalse" is a method defined in
class Boolean and also in two subclasses of Boolean: 1) class True and 2)
class False.  Class True implements the "ifTrue/ifFalse" method by simply
executing (invokes the "value" method on the code block object) the first
block  -- the one associated with the "ifTrue" argument keyword (ignoring
the second one).  Class False implements the "ifTrue/ifFalse" method by
executing the second code block -- the one associated with the "ifFalse"
argument keyword (ignoring the first).  The names "true" and "false" refer
to singleton instances of classes True and False, respectively.  So to do
an "if/then/else" conditional in Smalltalk, you write an expression that
evaluates to a boolean (i.e., either the "true" object or the "false"
object) and invoke the "ifTrue/ifFalse" method defined in that boolean
object's class (class True or class False) on that resulting boolean
object.  Depending on *which* boolean object your expression returns -- and
hence which boolean class (class True or class False) is involved, you
execute either the "true part" or the "false part".  The interesting point
is that Smalltalk uses "method-override polymorphism" as the basic way of
implementing conditionals (and essentially all other control structures).
This was actually one of the goals of Smalltalk-80: try to see how many
language constructs could be defined using *only* the mechanism of invoking
a method on an object.


>The syntax-sugar
>difference is large indeed, when compared to either the
>Smalltalk syntax OR Python's own builtin "special forms"
>such as if/else.  The fact of having to name your code
>blocks before you pass them as unevaluated-arguments
>takes no semantic power away, but in practice this is
>not a very frequent Python idiom -- most Pythonistas
>just don't often code that way, and some of those who
>DO (such as, yours truly:-) affect a deep indifference
>for "mere syntax-sugar issues", so there's no pressure
>from either "constituency" to remove the "inconvenience"
>(at a syntax-sugar level) of having to name the blocks.
>[Personally, I *LIKE* giving my codeblocks names, though
>I choose more significant ones than 'ifTrue'/'ifFalse':-)].
>
>The "constituency for change" in this regard would thus
>appear to be limited to people who BOTH appreciate this
>"passing unevaluated codeblocks" programming style AND
>at the same time care a lot about the exact syntax-sugar
>to be used for the purpose.  Surely a non-null set, mind
>you.

Yep.  Count me in!!!  :-)

>There may be a further split of it between those
>who believe the obvious way forward would be to just
>supply some nice sugar for unnamed & unevaluated code
>blocks, and those who'd place even more emphasis on the
>sugary aspects by focusing on the 'macro' possibilities.

Here's one vote for the former.

>
>
>Alex

Jim