merits of Lisp vs Python

[Mark Tarver]

How do you compare Python to Lisp? What specific advantages do you
think that one has over the other?

Note I'm not a Python person and I have no axes to grind here. This is
just a question for my general education.

Mark

[philip.armitage]

Paul Rubin wrote:

André Thieme <ad************ *************** *@justmail.dewr ites:

which isn't purely a matter of token count. And if (+ 2 3) were
really as easy to read as 2+3, mathematics would have been written
that way all along.

Maybe I am a "mutant" as Ken suggests but while mathematicians may
think in terms of infix, programmers have got very used to:

function (arg, arg, ...)

So when I see (+ 2 3) I just think function 'add' with arguments 2 and
3. Yep, I've moved the parens and removed the comma but that just makes
it even clearer. Then bring in more statement and you either have to
remember precedence rules (I can never remember those) or add some
parenthesis (oops!).

This may sounds paper thin to some people but if you appreciate
consistency then you'll appreciate the syntax.

Phil

[William James]

André Thieme wrote:

greg schrieb:

Ken Tilton wrote:

The reason I post macro expansions along with examples of the macro
being applied is so that one can see what code would have to be
written if I did not have the defskill macro to "write" them for me.

It seems to me your brain is somewhat stuck on the use of macros.

That you see it this way is normal.
A BASIC programmer would tell you the same thing. He can show you
solutions that don't use classes, methods or functions.
Some sweet gotos and gosubs are enough.
The idea is that macros save you tokens and allow you to experess
in a clearer way what you want to do. But in no case one "needs"
them to solve a programming problem. All what Kenny showed could
be done without his macro. It would just be a bit more complicated
and the resulting code wouldn't look good.

You're looking at the expansion of your
macro and assuming that you'd have to write all that
code by hand if you didn't have macros. You're not
thinking about alternative approaches, which could
just as well be used in Lisp as well as Python, that
are just as compact yet don't make use of macros.

He wouldn't have to write the full expansion. With functional
programming he could also solve it, but then he would need
a funcall here, a lambda there. And his code would not look
so understandable anymore, because it is filled up with some
low level details.
I will take one of the first macro examples form "On Lisp".
Let's say for some reason you want to analyse some numbers
and do something depending on their sign. We want a function
"numeric if":

def nif(num, pos, zero, neg):
if num 0:
return pos
else:
if num == 0:
return zero
else:
return neg
In Lisp very similar:
(defun nif (num pos zero neg)
(case (truncate (signum num))
(1 pos)
(0 zero)
(-1 neg)))
Now one example Graham gives is:
(mapcar #'(lambda (x)
(nif x 'p 'z 'n))
'(0 2.5 -8))

which results in the list (Z P N).
You can do the same thing in Python.
But it gets hairier if we want to make function calls that
have side effects.
Let me add these three functions:

(defun p ()
(print "very positive")
"positive")

(defun z ()
(print "no no")
"zero")

(defun n ()
(print "very negative")
"negative")
And now see what happens:

CL-USER(mapcar #'(lambda (x)
(nif x (p) (z) (n)))
'(0 2.5 -8))

"very positive"
"no no"
"very negative"
"very positive"
"no no"
"very negative"
"very positive"
"no no"
"very negative"
("zero" "positive" "negative")

The messages were printed in each case.
To stop that I need lazy evaluation:
CL-USER(mapcar #'(lambda (x)
(funcall
(nif x
#'(lambda () (p))
#'(lambda () (z))
#'(lambda () (n)))))
'(0 2.5 -8))

"no no"
"very positive"
"very negative"
("zero" "positive" "negative")
I put the calls to the functions p, z and n into a function object.
In some languages it would look a bit cleaner, for example Ruby.
They have a single name space and don't need funcall and lambda is
shorter. But still, we need to add several tokens. Maybe Haskell has
built in support for that.

def p
puts "very positive"
"positive"
end
def z
puts "no no"
"zero"
end
def n
puts "very negative"
"negative"
end
def nif num, pos, zero, neg
send( num>0 ? pos : (num==0 ? zero : neg) )
end

[0, 2.5, -8].map{|x| nif x, :p, :z, :n}

### Another way #####

p = proc {
puts "very positive"
"positive" }
z = proc {
puts "no no"
"zero" }
n = proc {
puts "very negative"
"negative" }
def nif num, pos, zero, neg
( num>0 ? pos : (num==0 ? zero : neg) ).call
end

[0, 2.5, -8].map{|x| nif x, p, z, n}

[=?ISO-8859-15?Q?Andr=E9_Thieme?=]

Neil Cerutti schrieb:

That's not a real difficulty, is it?

CL-USER(mapcar #'(lambda (x)
(funcall (nif x p z n)))
'(0 2.5 -8))

Didn't you forget the #' before p, z and n?

>CL-USER(mapcar #'(lambda (x)
(nif x (p) (z) (n)))
'(0 2.5 -8))

"no no"
"very positive"
"very negative"
("zero" "positive" "negative")

And the first example also still works the same way.

That's the part that Python doesn't naturally provide, and I
believe, Python programmers don't usually want.

Then I have the solution:
they can build their own functional if.
Instead of

if x 10:
do()
something()
else:
foo()
They can say:

def blah1():
do()
something()

def blah2():
foo()
pythonIF(x 10,
# then
blah1,
# else
blah)

I personally thought the first version was the Python way.
Now let's admit that

nif number:
pos_then:
p()
zero_then:
z()
neg_then:
n()

is also the Python way. With just one problem: they can't have it.
André
--

[=?ISO-8859-15?Q?Andr=E9_Thieme?=]

William James schrieb:

I suppose that is Ruby code.
So my statement was correct when I said:
"In some languages it would look a bit cleaner, for example Ruby."

This is because it has a minimal syntax for "lambda".

def p
puts "very positive"
"positive"
end
def z
puts "no no"
"zero"
end
def n
puts "very negative"
"negative"
end
def nif num, pos, zero, neg
send( num>0 ? pos : (num==0 ? zero : neg) )
end

This code would work

[0, 2.5, -8].map{|x| nif x, :p, :z, :n}

See how you move away from the idea of an if.
Here you need to say :p, :z, :n.
That is not much better as Lisps #'

### Another way #####

p = proc {
puts "very positive"
"positive" }
z = proc {
puts "no no"
"zero" }
n = proc {
puts "very negative"
"negative" }
def nif num, pos, zero, neg
( num>0 ? pos : (num==0 ? zero : neg) ).call
end

[0, 2.5, -8].map{|x| nif x, p, z, n}

But will this version also work this way:
[0, 2.5, -8].map{|x| nif x, "p", "z", "n"}

You can't express it like an "if" in Ruby.
In Lisp it is like an IF and represents exactly what
we think.
IF in Lisp:
(if expr
(then-part)
(else-part))

nif in Lisp:
(nif expr
(positive-part)
(zero-part)
(negative-part))

It looks as if it were a construct directly built into Lisp.
If one wants one could even add some additional syntax, so
that it looks like:
(nif expr
positive:
(foo1)
(foo2)
zero:
(foo3)
negative:
(foo4))

If you regard that idea nonsense then I suggest you to not
use Rubys if-statement anymore. But instead program your
own version "RubyIF" so that in future you have to pass all code
inside blocks to your RubyIF function. If you *really* think
that the Lisp savings are not worth it, then you would begin
with my suggestion today.
André
--

[=?ISO-8859-15?Q?Andr=E9_Thieme?=]

William James schrieb:

def nif num, pos, zero, neg
send( num>0 ? pos : (num==0 ? zero : neg) )
end

btw, your nif body is built out of 13 tokens, so more
complicated than the Python version.
André
--

[metawilm]

Paul Rubin wrote:

I thought it was of some interest though I'm a little surprise by the
choice of CL rather than Scheme as a target.

In many aspects Python is a subset of CL. In CLPython, exceptions are
Lisp conditions with a custom metaclass (strictly spoken not portable
CL), Python (meta)classes are CLOS classes, methods are implemented
using hashtables and functions and CLOS generic functions, strings and
numbers have direct equivalents, hash tables implement dicts, Python
functions are funcallable CLOS instances, tuples and lists are Lisp
lists and vectors, generators are closures. Thus a great part of
implementing CLPython consisted of connecting already existing dots. I
found that quite amazing.

I'm still not sure about the mapping of Python strings to Lisp strings.
What happens with the following in CLPython?

a = 'hello'
a[0] = 'H' # attempt to change first letter to upper case

As CLPython mirrors Python semantics, this results in a TypeError. The
internal representation of an immutable Python string is a mutable Lisp
string, but there is no way you can actually modify it from within
CLPython.

Now in some cases modifying strings is dangerous (e.g. when stored in
an instance dict to represent an attribute), but in other cases it can
be completely safe. And modifying strings is a normal Lisp feature, so
it sounds strange to disallow it at all times. Maybe there should be a
way for the user to declare that he knows what he is doing, and does
not want the Python implementation to be "crippled" w.r.t. the host
language. Normally you start the CLPython interpreter using (repl);
maybe something like this would allow dangerous statements:

(let ((*strict-python-semantics* nil))
(repl))

Oh, and there is actually one way to modify Python strings in the
interpreter, namely using Lisp commands:

PYTHON(12): (repl)
[CLPython -- type `:q' to quit, `:help' for help]

>>s = "abc"

'abc'

>> (setf (aref _ 0) #\x)

#\x

>>s

'xbc'

>>type(s)

#<class PY-STRING @ #x10575342>

>>type(s) == str

1

>>s

'xbc'

>> (inspect _)

A NEW simple-string (3) "xbc" @ #x11548f6a
0-The character #\x [#x0078]
1-The character #\b [#x0062]
2-The character #\c [#x0063]
[1i] PYTHON(13): :ptl

>>>

[Neil Cerutti]

On 2006-12-15, André Thieme
<ad************ *************** *@justmail.dewr ote:

In Lisp it is like an IF and represents exactly what we think.
IF in Lisp:
(if expr
(then-part)
(else-part))

nif in Lisp:
(nif expr
(positive-part)
(zero-part)
(negative-part))

It looks as if it were a construct directly built into Lisp. If
one wants one could even add some additional syntax, so that it
looks like:
(nif expr
positive:
(foo1)
(foo2)
zero:
(foo3)
negative:
(foo4))

If you regard that idea nonsense then I suggest you to not use
Rubys if-statement anymore. But instead program your own
version "RubyIF" so that in future you have to pass all code
inside blocks to your RubyIF function. If you *really* think
that the Lisp savings are not worth it, then you would begin
with my suggestion today.

I don't know how to build a house. It doesn't make me want to
live in a cave. ;-)

--
Neil Cerutti
The third verse of Blessed Assurance will be sung without musical
accomplishment. --Church Bulletin Blooper

[=?ISO-8859-1?Q?Andr=E9_Thieme?=]

greg schrieb:

jo************@ hotmail.com wrote:

>Adding parentheses ... all this is a
burden specific to Python.

As opposed to Lisp, where all you have to do is
use parentheses... oh, er...

Lisp has no parens. An editor could support a mode where code
is displayed in written in trees. There wouldn't be a single
paren.

>By the way, you guys seem fixate on the parentheses of Lisp without
having the experience

I don't know about the other Pythonistas in this
discussion, but personally I do have experience with
Lisp, and I understand what you're saying. I have
nothing against Lisp parentheses, I just don't agree
that the Lisp way is superior to the Python way in
all respects, based on my experience with both.

Lisp is not superior in all respects. As soon you decide to use a
language you decide against other features.
Python is especially strong as a scripting language as that is the
domain of it.
André
--

[William James]

André Thieme wrote:

William James schrieb:

def nif num, pos, zero, neg
send( num>0 ? pos : (num==0 ? zero : neg) )
end

btw, your nif body is built out of 13 tokens, so more
complicated than the Python version.


André
--

def nif num, *args
send args[ 1 + (0 <=num) ]
end

[=?ISO-8859-1?Q?Andr=E9_Thieme?=]

William James schrieb:

André Thieme wrote:

>William James schrieb:

>>def nif num, pos, zero, neg
send( num>0 ? pos : (num==0 ? zero : neg) )
end

btw, your nif body is built out of 13 tokens, so more
complicated than the Python version.
André
--

def nif num, *args
send args[ 1 + (0 <=num) ]
end

send
|
|
[ ]
/ \
/ \
/ \
args +
/ \
/ \
1 ()
|
|
<=>
/ \
/ \
0 num

Okay, 9. Now it is at the complexity level of the Lisp
and Python example.
But how would a call to nif look like?
I hope it doesn't involve an extra operator to group the
args into a list or tuple. That would add more complexity to
each call - so one should better have a slightly more complex
nif because that exists only one time.

And can this nif now handle any input values, such as strings
or function objects?

The <=is called cmp in Python.
In Lisp it is called signum. The Lisp function has in general the
advantage that it keeps type information.
While Pythons cmp returns either -1, 0 or 1 the Lisp version can
also return -1.0 and 1.0 and also complex numbers:
(signum #C(10 4)) = #C(0.9284767 0.37139067)
André
--