merits of Lisp vs Python

[Bill Atkins]

Bill Atkins <atkinw at rpi.edu> writes:

> "every corner of the language"?  Please.  Why are you so post-happy
> when it's quite obvious that you don't know enough about Lisp to
> attack it?

In addition to macros that define classes or methods, a common macro
is the WITH-* macro, which sets up some kind of context, runs the body
inside that context, and then does some cleanup.

For example, my Lisp vendor, LispWorks, provides the macro MP:WITH-LOCK :

(mp:with-lock (*the-big-lock*)
  (do-something-atomic)
  (something-else)
  (almost-odone))

The generated first seizes a process lock called *THE-BIG-LOCK*, runs
the code in the body and then releases the lock.  I never have to
worry that I've taken a lock without releasing it, because LispWorks
has encoded that behaviour into MP:WITH-LOCK (and if they handn't,
this macro is trivial to write).

Now I can tell if I'm keeping a lock around too long because all the
code that appears inside this WITH-LOCK is all the code that I'm
locking.  Further, the generated code is surrounded by an
UNWIND-PROTECT, which means that if an error is raised or anything
abnormal happens in the dynamic scope of the UNWIND-PROTECT, Lisp will
run cleanup code as it flees back up the stack.  So if there is an
error in my code, it does not prevent other processes from seizing
that lock, because it will be released as the error is signaled.

Here is the expansion:

CL-USER 7 > (write (macroexpand '(mp:with-lock (*the-big-lock*)
                                   (do-something-atomic)
                                   (something-else)
                                   (almost-odone)))
                   :pretty t :case :downcase)
(let ((#:g17553 *the-big-lock*))
  (when (mp:process-lock #:g17553)
    (unwind-protect
        (progn (do-something-atomic) (something-else) (almost-odone))
      (mp::in-process-unlock #:g17553))))