from
<http://groups-beta.google.com/group/comp.lang.lisp/browse_frm/thread/2e2
76117925dcbe8/aab851df86f90be7#aab851df86f90be7>

-------------------------------------------------------------------

I run now, or have run, just about every common lisp that runs on Mac OS
 X. These include, in no particular order:

Armed Bear Common Lisp
 Allegro Common Lisp (trial version)
 MCL
 OpenMCL
 LispWorks (4.4)
 clisp
 cmucl
 sbcl

I'll rate these on the categories that would matter to most Mac OS X
 programmers - Carbon, Cocoa, speed (of compiled code), compiler, and
 issues (i.e., problems), and unusual features.

ABCL - Carbon: via java
  Cocoa: via java
  speed: slow
  compiler: slow
  issues: not fully ANSI compliant yet
  features: java based, so access to java libraries.

Allegro - Carbon: via ffi?
  Cocoa: no
  speed: moderate to fast.
  compiler: fast
  issues: No IDE on Mac OS X. Trial couldn't load vendor supplied
 patch. Expensive. Royalties on delivered apps. (i.e., imho not ready
for
 prime time on Mac OS X, especially if you're interested in GUI apps).
  features: runs on Windows and unix/linux, so should be very portable.
 Large user community. Excellent and abundant contributed code. Java
 access.

MCL - Carbon: excellent Carbon support - best of any lisp.
  Cocoa: no (i.e., only via Carbon).
  speed: moderate to fast, slow floating point and arrays.
  compiler: blazingly fast.
  issues: Digitool chose the Carbon route to port from Mac OS Classic
 to Mac OS X. As a consequence, MCL's Cocoa support is lacking. In
 addition, MCL itself, as well as delivered applications are *not* Mac
OS
 X bundles - they are single files with a resource fork. This is a
 problem as unix tools can unwittingly strip the resource fork of MCL
 apps.
  features: Unsurpassed Carbon support. Nice IDE. Friendly user
 community. Lots of contributed code. Royalty free app delivery with
 deployment license.

OpenMCL - Carbon: excellent Carbon support.
  Cocoa: very good cocoa support.
  speed: moderate to fast, slow floating point and arrays.
  compiler: blazingly fast.
  issues: As of this writing, app bundles and the alpha IDE need to be
 recompiled for every point update of Mac OS X. This effectively
prevents
 distribution of finished apps (i.e., users would have to download a new
 version every time they used Software Update and went from Mac OS X
 10.3.7 to 10.3.8 for example.) IDE is primitive.
  features: Friendly user community. Free as in beer and speech (llgpl)
 - no redistribution issues unlike gpl because of the preamble of the
 llgpl. Cocoa bridge.

LispWorks - Carbon: via ffi, but Cocoa is the expected GUI framework
 with LispWorks.
  Cocoa: excellent Cocoa support.
  speed: very fast
  compiler: moderately fast
  issues: CAPI, LispWorks cross platform GUI API, is not fully HIG
 compliant. Mac OS X GUI is not multi-threaded unlike Windows version.
  features: Excellent IDE. Friendly user community. Good, abundant
 contributed code. CAPI allows easy cross platform development to
Windows
 and Linux. Royalty free application delivery. Best lisp for Cocoa GUI
 development, especially if you want an IDE.

clisp - Carbon: via ffi? (don't know if callbacks are possible)
  Cocoa: not that I'm aware of.
  speed: generally slow to moderate, but fast bignums.
  compiler: moderately fast
  issues: No IDE. Not native compiled (bytecode). GPL (so should be
 aware of license issues if redistributing).
  features: very widely cross platform - Windows, Linux, unix, Mac,
 FreeBSD, etc. Free as in speech and beer - GPL.

cmucl - Carbon: via ffi? callbacks?
  Cocoa: not that I'm aware of.
  speed: moderate to fast.
  compiler: slowish (see sbcl for comments).
  issues: Not as widely used or developed/maintained on Mac OS X as its
 fork, sbcl.
  features: widely cross platform. optimizing native compiler.

sbcl - Carbon: via callback system.
  Cocoa: not yet.
  speed: blazingly fast - fastest generated native code all around of
 any Common Lisp (with LispWorks close behind).
  compiler: slow, but then, it does a lot of optimizing and generates a
 lot of notes to aid programmer in optimizing source.
  issues: Not really ready for prime time for GUI app delivery - Carbon
 callbacks are still a new feature and there is no IDE.
  features: very widely cross platform, and generated code is
 unexcelled among Mac OS X common lisps.

Since I'm interested in Cocoa GUI apps, I use LispWorks. I'd use OpenMCL
 if one didn't need to recompile and redeliver apps for each OS point
 update, but OpenMCL is not quite ready for prime time for GUI app
 delivery. MCL is nice, but too slow for float and/or array intensive
 code, and I don't want to deliver apps that have resource forks, and
I'd rather use Cocoa than Carbon.