Benefits of moving from Python to Common Lisp?

Marco Antoniotti marcoxa at cs.nyu.edu
Sun Nov 11 22:44:54 CET 2001


"Morten W. Petersen" <morten at thingamy.net> writes:

> Hello,
> 
> I'm currently doing some research, to see if it could be an advantage to
> use Common Lisp instead of Python (currently Python and Zope [1] are used
> to build web applications).
> 
> While doing this, Google has provided two interesting documents (search
> for 'lisp vs python'):
> 
>   http://www.strout.net/python/pythonvslisp.html

The above page contains several factual errors about Common Lisp.  It
is not a good summary and it is misleading, especially about Common
Lisp. As such it must be disregarded.

>   http://www.norvig.com/python-lisp.html

This is a very good document, by a person with a very good reputation
and who knows what he is talking about.

> First off, to save everyone some time, I'm wondering if there are more
> papers documenting the difference between the two;  if there aren't any,
> I'd like to continue the discussion and summarize the findings in a paper
> accessible on the net.

There are a number of (maybe obscure) advantages to Common Lisp
w.r.t. Python.

Apart from the existence of very good native compilers, there are a
number of nice features - all standard - that allow you to use Common
Lisp as a "language kit": something very few other language are good at.

Take for example one of the latest additions to Python: list
comprehension.

This is essentially incorporating regular set-theoretic notation in
the language. I.e. to have notation that allows you to say things like

	{x | even(x) /\ x >= 0 /\ x <= 100}

(the set of "numbers" between 0 and 100 - assuming integers or rational,
this is a finite, enumerable set).

To get this kind of notation into Python (alas a similar one), AFAIU,
the (1) parser had to be modified, and (2) the interpreter had to be
modified as well. This are not things that (AFAIK) where done in
Python itself.

In Common Lisp you just changed the "readtable" to recognize the
special nature of the characters #\{, #\}, #\[, and #\] (think of
Emacs and what it does with characters) and you write a couple of
macros.  The code is all written in CL and the above example may be
rendered as

	{x / x in (range 0 100) / (evenp x)}

This effectively constructs a list of the even integers.  All of this is
all CL and it is all compiled down to native code. (The above expression
"expands" into a LOOP, which is happily compiled by the CL system.  The
code runs on all CL implementations and it can be used to shorten your
programs.

Here is a better example of legal CL code constructing a list of the
prime numbers from 3 up to `max'.

(defun primes (max)
  [n in (range 3 max 2)
     / (not (exist m in (range 3 (min (1- n) (+ 2 (sqrt n))) 2)
                      / (= (mod n m) 0)))])

(Note the optional indentation! Of course you can use the INFIX
package to write the customary 2 + sqrt(n), but that is just another
trick you can do with Common Lisp).

Again the above is legal CL (once you load the appropriate 300 lines
of code) and it gets compiled to native code.

Of course the underlying data structure for "set" is naive, but that
is a different problem.  Given time you could implement spme
hash-indexed B-tree representation for sets and replace with that the
guts of the notation rendering.  All of that can easily be done in CL.

Cheers

-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group        tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA                 http://bioinformatics.cat.nyu.edu
                    "Hello New York! We'll do what we can!"
                           Bill Murray in `Ghostbusters'.



More information about the Python-list mailing list