About a week ago, I posted a notice to comp.lang.lisp asking people
for a comparison of Lucid (Sun) Common Lisp and Allegro (Franz) Common
Lisp.  Here is a summary of the responses I have received to date.

   One of the responses I received was a summary of the responses to a
similar question which was posted on the net about a year and a half
ago.  (This summary included a response from a Franz employee.)  I
received one response from an employee of Lucid, and four responses
from people with no stated affiliation.  (One of those was from a
person who has spent a considerable amount of time researching exactly
this topic, for professional reasons.)  Since I, myself, have
experience with both dialects, I counted my own opinion as worth one
vote.  Also, I received a pointer to an article in the June, 1989
edition of Unix Review, which I counted for one vote.

   I'll start by trying to summarize the flavor of the responses, and
I'll follow that with the (edited) text of some of the responses.

   Notice that both of these sections are useful in different ways!
The summary includes the opinions of various people who would not
allow me to quote them verbatim, but would allow me to tabulate their
"votes".  It also contains information from the magazine article,
whose text I did not include.  Nevertheless, despite my best attempts
to keep it objective, I have no doubt that various biases of my own
have found their way into the summary.  (But please realize that I
have no professional affiliation with Sun or with Franz, nor do I have
any other reason to care in the slightest which company ends up
looking better.)  To minimize any bias, I have specified which votes
in the summary came from the Lucid employee, the Franz employee,
myself, or any out-dated sources.  The verbatim text, while not
including all of the messages, contains a wealth of detail not
included in the summary.

   The summary:

   The two issues which spawned the most disagreement were those of
execution speed and overall compiler quality.  Two unaffiliated
sources claim to have done speed comparisons:  One claimed Lucid was
faster by almost a factor of two.  The other (the magazine article)
claimed Franz was faster by at least a factor of two.  This may be
partly explained by the fact (agreed upon by everyone who commented)
that Lucid's memory requirements are much larger than those of Franz.
So the execution speed may depend upon how much memory you have.  (If
this is the case, then the picture is further confused by the fact
that Lucid is now said to have a "tree-shaker" to reduce the size of
executables.  I dont know how well it works or if Franz has one.)
Overall, out of 5 respondents who had an opinion, 3 had more praise
for Lucid's speed and 2 had more praise for Franz's speed.  But the
two that preferred Franz's speed were the Franz employee and the
magazine article - both rather out-dated sources.

   One respondent claimed the Franz compiler was buggy and produced
buggy code on at least two different examples of correct Lisp source.
(But it is not clear to me how recently that experience occurred.)  The
Franz representative, paradoxically, praised the accuracy and safety
of their compiled code as its most salient feature.  No one else had
any complaints or compliments about either compiler's accuracy.

   Two respondents thought that Franz was "buggy", but one or both of
those were running an out-dated version.  A third source (myself),
thought that Lucid had more incompatibilities with Steele, volume I.
One source claimed that Lucid covers Steele, volume II, and Franz does
not.  Three out of four people who commented seemed to prefer Franz's
extensions to Steele.  (The fourth was the Lucid employee).  Two of
those who preferred Franz specifically mentioned Franz's run-program
function - so this observation might be biased by the emphasis my
original note placed on this one feature.

   Window support:  Reading between the lines, I infer that Franz has a
longer history of supporting X windows than Lucid, but Lucid supports
more different windowing systems.  (One respondent thought that Lucid
still does not support X windows, but I'm inclined to disbelieve this
because another person claims to have used it.)  I'm told they both
support Common Windows now.  One person expressed a marked dislike for
Lucid's window tool kit.

   All six people who commented on support (including one Franz
employee, and including myself) thought Franz had better customer
support than Lucid.  The praise for Franz's support was nothing short
of stellar.  Three people mentioned that Franz usually responded
within 24 hours, and the response usually included a patch or a
workaround.  One person said that Lucid could not provide patches.

   Out of six sources who commented on the tty de{*filter*} (including the
Lucid employee, the Franz employee, myself, and the magazine article),
all but one preferred the Lucid de{*filter*}.  The one exception, the
Franz employee, thought they were comparable.  This does not include
the few comments I got concerning window de{*filter*}s, which seemed too
vague to summarize.

   Three sources (including the magazine article) mentioned that Franz
is cheaper.

   One of the older responses said Franz was "becoming the most common
version".  But one person pointed out that ART and KEE run in Lucid,
but not in Franz.

   Two voters (the magazine article and myself) favored Franz's
documentation over Lucid's for readability.  But one person thought
Franz's documentation did "not match up" with its code.

   Now follows the verbatim text of the responses I got.  I have
edited out the following things, and nothing else:

        - some clauses identifying the author or other sources
        - messages from people who asked not to be quoted
        - messages from people who asked for a copy of this summary,
          but who did not provide information on the topic.
        - the text of the Unix Review article
        - anything that appeared to be both an adverti{*filter*}t and
          irrelevant to the topic

   I have included various responses written in German, although I
have not summarized them since I cannot read German (and the messages
are rather dated anyway).

--------

Date: Thu, 21 Mar 91 19:24:07 PST
Subject: Re: Lucid (Sun) Common Lisp vs Allegro (Franz) Common Lisp

Hi.  I work for Lucid (as the From line shows) and I'd be interested to see
what kind of responses you get.

Based on opinions I formed before I work here, I think the Lucid de{*filter*} is
much easier to use than the Allegro one, and I think the set of extensions
that Lucid provides are better than Allegro (I felt like it was a very
letter-of-the-law-and-nothing-more implementation.)

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

Subject: Lucid vs Allegro
Date: Mon, 25 Mar 91 11:15:17 EST

We now use Lucid exclusively, though in my previous group we used
Allegro for a short while.  I think Lucid is better, but see
below.

 If you are porting code from a Lisp Machine, you will find that Lucid
is much more of that "flavor".  They have a number of extensions in
the LCL package which duplicate useful functions from Symbolics.
Allegro was more MACLISP like.

 My general impression was that Allegro was buggier (this was a
version from about 2 years ago.)  Some basic things like arrays with
fill pointers were occasionally not handled correctly.  Lucid bugs
were rare and esoteric.

  Allegro had ERRSET, a pretty primitive error handling mechanism.
Lucid has had the full Pitmann condition system for the past two releases
(maybe Allegro does too, now).
 Lucid has a much nicer foreign function interface.  More complete and
robust.

 Franz is *extremely* responsive to bug reports.  This was our only
complaint with Lucid, but they fixed that problem [...] at least.

 Lucid has a very nice production-mode compiler, with very informative
reports on what it optimized, or why it could not optimize something.
The development-mode compiler is blazing fast.

 Lucid's seemed more complete.  Also, it "feels" like the Symbolics
de{*filter*} (eg, you type :b for a backtrace instead of control-B, etc).

 - window systems
 Stay away from Lucid's window tool kit -- it's a crock.  I don't
known what Franz offers.  CLIM is almost real, anyways.

 - arithmetic
 Lucid uses double precision for all "free" floats (not in a slot of a
SINGLE-FLOAT array).  If you are doing much floating point arithmetic,
Allegro *may* be faster and/or cons less.

 - size
 One advantage of Allegro was a somewhat smaller Lisp image.  But now
Lucid offers their "tree shaker" with v4.0, which compensates.

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

Date: Mon, 25 Mar 91 12:45:07 PST
Subject: Re: Lucid (Sun) Common Lisp vs Allegro (Franz) Common Lisp

This may have nothing to do with the sorts of applications you'll be using, but
I had some severe problems accessing an Oracle database using SQL embedded C routines
called through the foreign-function interface.  I think it may have been caused
by Lucid redefining signals.  

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

Date: Mon, 25 Mar 91 17:23:53 -0500
Subject: lisps

To summarize my concerns about Allegro:

1. The Allegro compiler is unreliable. Perfectly good code, that
meets the common lisp specifications and compiles perfectly on
symbolics and Lucid, either does not compile at all (incorrect
compiler errors), or compiles incorrectly with Allegro. The most
disturbing thing that has happened to me personally is that
interpreted and compiled code give different results with
Allegro.  [name deleted...] tells
...

read more »

Lucid's support seems to have gotten noticeably better in the last month.
I've gotten about four patches in the last three weeks.  Unfortunately, one
of the patches introduced a new, worse bug....
--
Barry Margolin, Thinking Machines Corp.

{uunet,harvard}!think!barmar

Lucid is not you're ordinary, well-behaved X-client.  For example, Lucid
ignores user default resource values for such things as window colors,
title bars, etc in your .Xdefaults file on Unix.

Lucid has their own environment when running under X.  Allegro tends to
fit better in the environment, especially Unix.

Nat

P.S. - opinions are my own, and have nothing to do with Digital Equipment
          Corporation.

Your summary was interesting an informative, but I would like to
caution people against basing any decision on it without further
investigation.  Indeed, a number of the comments seem to me to
be false.  I don't think anyone is being deliberately misleading,
but everyone will, of necessity, have only a partial picture.

Moreover, whenever someone says something such as "the compiler is
buggy" or "compiled code is slow", they really ought to say what
version of the system was used, what machine it ran on (and especially
how much memory it had), and what the program was doing.  A problem in
one area does nto necessarily show there are similar problems
elsewhere.

It often makes a huge difference which release of a system one uses.
Serious problems in one release are often fixed in the next, and
the major releases (3 vs 2, say) of Lucid and Allegro have involved
very significant changes (such as a different gc method or a new
compiler).

I have used a number of different Common Lisps over the years,
including several versions of Lucid (starting with 1.2) and two of
Allegro.  (I once counted the number of CLs on nearby machines and
found about 12, though there aren't so many now.)  All of them have
had some good features, and some bad ones.  I don't think I could make
a definite claim as to which one was best.

However, it's worth bearing in mind that there can be good reasons
for choosing one over another quite apart from which one is really
best.  For example, if you want to run ART or KEE on a Sun, you'll
need Lucid.  If you have a small machine and are not going to run
huge programs (because then you'll lose anyway), you may do well
to use KCL.

I have not made a direct comparison because I have never had both
on the same hardware.  This is about to change, so get back to me
in about a month.

Franz is supposed to have a similar facility, but I don't see anything
about it in the 4.0 User Guide.

People here have encountered bugs in both Lucid and Allegro.  I don't
have a good feel for which is more sound.

We still run KEE in version 2.1 of Lucid because (I am told) of bugs
in version 3.  However, the bugs are not so severe that we do not also
use KEE with version 3.  On Sun 3/260s with 16 megabytes of memory
(but different versions of SunOS), the 2.1 version is faster for
smaller applications but slower for larger ones.  Faster still is
a 3/60 with 24 megabytes (and KEE on Lucid 3).  So the amount of
memory is very significant.

So far as I can tell, both have some things from CLtL II but not
all of them.

Someone claimed that Allegro did not use the new CL condition
system.  According to the Rel 4.0 User Guide, that is not true;
but I have not yet installed the system and found out exactly
how it works.

It is certainly not the case that Allegro is a "letter-of-the-law-and-
nothing-more" implementation.  It has stack groups, processes, weak
vectors, an advice facility, Flavors, Common Windows, etc.

Both Allegro and Lucid can run programs, and both have a foreign
function interface.  Their capabilities seem roughly equivalent,
but I'd have to check to be sure.

I don't know how well Ludid works with X.  At least thought Rel 3,
it created a single window in Sunview and then did its own windows
inside it.

I found the Allegro tty de{*filter*} (Rel 3) very uninformative.  This
is somewhat strange since I don't feel the same way about the de{*filter*}
in Composer and they supposedly provide the same information.

Lucid seems to provide better support for tracing and debugging local
functions (defined by FLET or LABELS).

Ibuki is based on Kyoto Common Lisp (KCL).  The KCL compiler emits
C code.  I think it's unfair to call it a preprocessor, because that
might be taken to imply a more direct translation then is actually
the case.

The main problems with compiling to C are that it is harder to do
some optimizations and that compilation is much slower.  On the other
hand, KCL is very portable and, if you use a good C compiler, the
final code can be very good.

-- jd