User Tools

Site Tools


lisp_on_osx

Lisp and Mac OS X

a gentle introduction > http://www.advogato.org/person/johnw/diary/11.html


A comparison of various common lisp implementations which run on MacOSX.

(NOTE: freely lifted from Bill Clementson's Blog, which was in turn a summary of a c.l.l thread (or 2, or 3…) http://home.comcast.net/~bc19191/blog/050327.html still needing some wikification, clarification of the commentry, and so on…) previous blog posts

c.l.l threads

  • Common LISP Implementations for Mac OS X?
  • MCL for OS X worth the price?
  • What Lisp for Mac OS X with these requirements?
  • Graphics in MCL or LispWorks? (OS X)
  • Raffael Cavallaro's summary of the different CL implementations that are available on Mac OS X.

implementations [as of 2005]

“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 (ABCL), Allegro Common Lisp (trial version), MCL, OpenMCL, LispWorks< (4.4), CLISP, CMUCL, SBCL” – Raffael Cavallaro

I'll rate these on the categories that would matter to most Mac OS X programmers - Carbon, Cocoa, speed (of compiled code), compiler, 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. (Note: This is a surprising ranking by Raffael and doesn't correspond with some other people's tests nor my own impressions as I've found Allegro to be very fast on the Mac. Raffael was using the trial version of Allegro and this is not really a fair basis for a speed comparison. Also, with regards to benchmarking CL implementations, see my comments at the end of this posting)
  • 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 <strong>not</strong> 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. MCL has an ephemeral garbage collector (essential for continuously animated stuff).

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. Native thread support. Free as in beer and speech (LLGPL) - no redistribution issues unlike GPL because of the preamble of the LLGPL. Cocoa bridge.

LispWorks

HIG</a> 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. LispWorks uses native threads for its multiprocessing, but, unfortunately, the LispWorks CAPI GUI on Mac OS X puts all GUI interaction in a single thread (possibly because this is easier - portions of the AppKit are not thread safe).

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 and callbacks
  • Cocoa: not that I'm aware of.
  • Speed: blazingly fast.
  • Compiler: slowish (see SBCL for comments).
  • Issues: Not as widely used or developed/maintained on Mac OS X as its fork, SBCL.
  • Features: optimizing native compiler, callbacks. .

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.

notes

on the relative merits of MCL and LispWorks for Mac OS X development as well as the relative merits of Carbon/Cocoa for Mac development. http://groups-beta.google.com/group/comp.lang.lisp/browse_frm/thread/fe598c3715c9b092/612ae11f7c1357a3#612ae11f7c1357a3

benchmarking

lisp_on_osx.txt · Last modified: 2007/11/01 10:26 by 192.168.1.37