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 debugger (including the
Lucid employee, the Franz employee, myself, and the magazine article),
all but one preferred the Lucid debugger. The one exception, the
Franz employee, thought they were comparable. This does not include
the few comments I got concerning window debuggers, 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 advertisement 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 debugger 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.
> - Difficulties in translating existing Lisp code (not
>necessarily Common Lisp) to Lucid or Allegro.
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.
> - Bugs - situations in which the implementation is clearly
>contrary to Steele.
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.
> - Things you needed to do and couldnt, even if Steele doesnt
>require it. (Things like ERRSETs and communication with Unix/other
> programs, perhaps.)
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.
> - The company's responsiveness to questions and bug reports.
Franz is *extremely* responsive to bug reports. This was our only
complaint with Lucid, but they fixed that problem [...] at least.
> - Difficulties in compilation.
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.
> - Preferences in debuggers.
Lucid's seemed more complete. Also, it "feels" like the Symbolics
debugger (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 me that the Allegro compiler
has a bug that caused a correct defstruct expression to hang her
machine translation system and fill her 150MB disk.
Also, the Allegro compiler catches fewer bugs at compile time
than the Lucid compiler does. The overall effect is to serious
reduce my confidence in the Allegro compiler.
2. Relevant NLP benchmarks, performed at UMD and at MIT,
indicate that Allegro's object code is slower than the code
produced by Lucid or Harlequin, and that the Allegro compiler is
itself slower than Lucid.
3. The Allegro debugger is unusable. Looking at the stack frames
does not give sufficient information for effective debugging.
4. Allegro is incomplete. Unlike Lucid, it does not implement
Steele second edition. Also does not support crucial interface
extras, like run bars. And at least for the DEC 5000 version,
the documenation and code do not match up, for example, on the
effects of type declarations.
I am aware that Lucid has it's own problems, such as its large
image, bad customer support, and no X window interface. But as
things stand, I'd rather deal with those problems than that of
an unreliable compiler or bad debugger, plus inefficient code.
Please let me know what your experiences have been.
Thanks,
------------
Date: Fri, 22 Mar 91 09:54:01 CST
Subject: Re: Lucid (Sun) Common Lisp vs Allegro (Franz) Common Lisp
Found this in the attic someplace.
[Now follows the summary of the previous posting. All of these
comments are nearly a year and a half old --ed]
Subject: Summary: Lucid vs. Allegro
Date: 23 Nov 89 09:10:43 GMT
Recently I posted an article to comp.lang.lisp in which I asked for a
comparison of Lucid and Allegro, both for the Sun 4.
The first reply I got was from Steve Anderson of the Cognitive Science Center
at Johns Hopkins, who urged me to post a summary. Well, here it is:
Actually, there seems to be much interest in this comparison; I got lots of
replies asking for a summary. But there does NOT seem to be much experience in
using one (or preferably both) of the systems in question; I only got 8 real
answers, but 3 of them are comming from vendors.
2 of these ones are talking about other systems: the first is Ibuki CL, which
is --- as far as I know --- a preprocessor to C; the second one is called
LispWorks (I've never heard of this but I would be interested if anyone else
has).
In a magazine I found an article comparing Lucid, Allegro and Ibuki. The final
ranking was: Allegro first, followed by Lucid, and then Ibuki. If you are
interested in the details, the article is the following:
A Look at LISP Compilers
by Nader Kameli
UNIX Review, June 1989
In the following, I append the answers I got.
My final impression is:
Allegro seems to be the prefered product,
but the description of the LispWorks system sounds interesting.
Thanks again for all of the replies
Carsten Schroeder
P.S. One of the replies, which came from Harold Boley at the DFKI, got lost
somewhere in my mailbox. Could you please send it again, Harold?
C.S.
Subject: Allegro Common Lisp.
Date: Wed, 8 Nov 89 12:30:16 PST
We've been on a Sun 3 until recently, but most of what I know applies to Sun
4s.
We've chosen Allegro over Lucid, for the following reasons:
-- Allegro Composer is/was integrated with X11, while SPE (Lucid) was
integrated with SunView. Now, this might matter less in the future,
when XView comes out, so maybe SPE will soon work in X as well.
-- Composer works within GNU emacs, SPE has its own editor. This has
advantages and disadvantages. GNU is (as you know I'm sure) very
mature, we were loath to give it up. Of course, the SPE editor has
the advantage of being in the same name space as the listener, with
lots of advantages there. I really don't have a good feel for how
good the SPE editor is.
-- Speed: on some of our programs, Lucid has been far faster, but on my
system, lucid and franz are pretty similar, so I'm not sure if this is
an issue.
-- Support: I'm in a very different situation here, since I work 5
minutes from Sun and 20 minutes from Franz Inc. However, I think
support is a big plus for Franz; they're a 30 (?) person company, I've
been able to speak directly, for instance, to the head of the
development group for composer about something I want.
In general, SPE might be a bit more mature at present, but I think for the
long run Composer and Franz Inc have advantages. I should say, however,
that on a Sun3 Composer is slow enough that I don't find it that useful.
However, I believe this to be true also for SPE.
Good luck. If you get other substantitive comments, your forwarding them to
me would be appreciated, we're still able to change our mind in future
purchases.
--------------------------------------------------------------------------------
Date: Sat, 11 Nov 89 21:54:21 EST
hi guy.
I am not realy the guy to ask about lisp on the suns.
I believe we have allegro (cl). The reason for getting it
was 1) it is cheap compared e.g. to lucid. 2) also it is
becoming the most common version so that much of the current
software is written in allegro. Heeger's image processing package
was written for lucid, but guiys here have it running under
allegro. that's it really.
the person most familiar with the issues would be evangelos milios.
his login is eem.etc. I don't know if you know him though.
anyway that's my little bit of info for you.
later, david.
--------------------------------------------------------------------------------
Subject: Re. Sun Common Lisp vs. Allegro Common Lisp
Hallo in Hamburg,
wir hier in Berlin verwenden seit ca. 4 Wochen Allegro CommonLisp
(Version 3.1) auf einer Sun 4/110. Generell sind wir ganz zufrieden
damit. Mit SPE und Sun CommonLisp haben wir leider keine Vergleichs-
moeglichkeiten.
Vorher haben wir mit Delphi CommonLisp gearbeitet (kommt aus Italien,
hat CLX und erste CLOS-Implementation). Damit konnte man aber nicht gut
arbeiten, daher faellt der Vergleich evt. zu gut fuer Allegro aus.
Nun zu den einzelnen Punkten.
-- usability and comfort of the environment, esp. the debugger
Stepper, Tracer, Inspector und Debugger machen einen guten Eindruck,
insbesondere der Debugger gibt recht gute Aufschluesse. Besonders gut ist die
Lisp-Emacs Schnittstelle, die von Franz erweitert wurde und viele
Moeglichkeiten bietet, die man so von Symbolics kennt. Au~erdem gibt es
dann ja noch den AllegroComposer (Zusatzpaket) der eine
fensterorientierte Oberflaeche zum Debugger und Inspector bietet. Das
sieht auch alles ganz nett aus, aber die Performanz geht selbst bei der
Sun 4 in die Knie.
-- performance
Die Ladezeiten sind ziemlich lang, besonders beim Starten. Ansonsten
kann man nicht meckern.
-- interface to C and UNIX, esp. possibility to call C routines from LISP,
and vice versa
Es ist wohl moeglich, und es gibt spezielle Schnittstellen fuer beide
Richtungen (C - Lisp). Damit haben wir aber keine Erfahrungen.
-- interface to suntools, esp. SunView, and OpenWindows (X)
Es gibt eine eigene Fenster-Software (CommonWindows, auch Zusatzpaket),
die mit SunView und X11R3 zusammenpasst. Wir arbeiten hier mit CLX
(public domain Version wird mit AllegroCL mitgeliefert).
-- does the compiler conform to the same semantics as the interpreter?
Wir haben noch nichts gegenteiliges feststellen koennen.
-- bugs
-
Hoffentlich konnten wir ein wenig helfen.
Wir waeren sehr dankbar, wenn wir die Ergebnisse der Anfrage ans Netz
erfahren duerften, da wir ja auch erst anfangen.
Falls das AllegroCL bei Euch zum Einsatz kommt, kann man ja vielleicht auch
zwecks Erfahrungsaustausch in Kontakt bleiben.
Bis dann, Tschuess
--------------------------------------------------------------------------------
From: ··························@unido (Bill Carlson)
Date: Mon, 6 Nov 89 09:13:22 PST
Subject: Allegro CL
[This is from the person at Franz --ed]
Hello,
I saw your mail on the net. Although I am somewhat biased in my opinion
of Allegro CL, I'd like to respond to your inquiry directly.
Our X-based environment, Allegro CL with Common Windows and Composer, is
compact (will run inside of 16MB on SPARC) and offers many
easy-to-use facilities. The following is your mail with my
comments inserted.
-- usability and comfort of the environment, esp. the debugger
Our philosophy is to NOT re-invent the wheel, but to take
to advantage of and integrate commonly used tools
like GNU-Emacs, X-windows many features of Berkeley Unix.
We've include things like meta-dot, on-line documentation,
"history", "bang-bang" etc... within the Lisp top level
and more.
On a feature by feature comparison, the tty debugger is
comparable to Sun CL's debugger. In Composer,
the windowized debugger is powerful and informative. Like other
facilities, the debugger pops up in its own customizable
window for ease of use and to clearly display debugging
information.
-- performance
Allegro CL's compiler was rewritten for SPARC and compiles
extremely fast. Allegro CL produces extremely safe and
accurate code while running at ALL settings.
Execution speed is about the same as Sun CL except on
smaller machines where Allegro CL is much
faster due to Sun CL's paging. This is especially true
on SPARCstations with slow disks.
-- interface to C and UNIX, esp. possibility to call C routines from LISP,
and vice versa
With Allegro CL you can have Lisp call C, or C call Lisp. This feature
is well documented, well tested and very easy to use.
-- interface to suntools, esp. SunView, and OpenWindows (X)
For compatibilty reasons, we are putting our energies into X
rather than proprietary window systems.
We interface to X via CLX and have had an X-based
product longer than any Lisp vendor.
We do have an interface to Sunview where we allow you to
call every SunView function directly from Lisp.
-- does the compiler conform to the same semantics as the interpreter?
Yes.
-- bugs
Our product is well tested and well debugged.
This brings up support, perhaps one of the best reasons to purchase
Allegro CL. Franz Inc. has a reputation for having the best support
in the industry. Our policy is to respond to any inquiry within the
day. You may contact us by phone, Email, Fax, Telex or mail and in
many cases talk directly with the core technical people who wrote the
code. Maintenance is included free for one year with all licenses.
Price is perhaps the last reason to buy Allegro CL,
but it is fair to point out that we offer generous
academic discounts and site licenses. The following
prices are for Sun 4/Sparcstations:
Product Standalone Diskless Site
====================================================
Allegro CL $1,875. $937.50 $15,625
Common Windows 312.50 156.25 3,125
Composer 625. 312.50 6,250
Our price list will offer more information on additional discounts
and machine availability.
I am sending you more information by airmail.
Please do not hesitate to contact me anytime if you have any
questions or concerns.
Regards,
Bill Carlson Franz Inc.
Sales Manager 1995 University Avenue, Suite 275
INTERNET: ·······@franz.com Berkeley, CA 94704
UUCP: uunet!franz!carlson 415-548-3600, FAX:415-548-8253
--------------------------------------------------------------------------------
Date: Mon, 6 Nov 89 08:48:00 -0100
Subject: Allegro vs. Lucid
Carsten,
ich weiss ein bisschen was ueber dieses Thema:
- performance: allegro ist angeblich schneller und etwas kleiner. ich
glaube, dass das anwendungsabhaengig ist, man sollte es auf jeden fall
mit seiner anwendung ausprobieren. zu dem zweck kriegt man auch von
allegro (das wqird ueber die expertise in berlin vertrieben) eine
evaluation copy. alle beide sind auf der sun-4 wohl sehr schnell,
solang man nicht pagen muss.
- das C-Interface ist bei beiden ziemlich aehnlich, beide aktiv und passiv.
- Allegro hat CommonWindows, das laeuft unter NeWS und unter X. Lucid
hat auch ein windowsystem, das laeuft unter Sunview, ich weiss nicht
ob es unter X laeuft. Und von OpenWindows hab ich noch gar nix gehoert.
Was soll denn das sein?
- bugs: haben sie wohl beide, aber wir konnten eine 40K LOC applikation
mit vertretbarem aufwand auf beiden rekompilieren - anpassungen sind
notwendig, aber beide produkte sind ziemlich stabil.
Wenn Ihr sonst noch irgendwas interessantes rausfindet, wuerdet Ihr
bitte mich auch informieen.
Danke,
From: Barry Margolin
Subject: Re: Lucid (Sun) Common Lisp vs Allegro (Franz) Common Lisp - the Summary
Date:
Message-ID: <1991Apr2.044801.24452@Think.COM>
In article <·····················@lexis.Princeton.EDU> ········@clarity.Princeton.EDU (Tim Weinrich) writes:
> One person said that Lucid could not provide patches.
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.
······@think.com
{uunet,harvard}!think!barmar
From: ······@databs.enet.dec.com
Subject: Re: Lucid (Sun) Common Lisp vs Allegro (Franz) Common Lisp - the Summary
Date:
Message-ID: <1991Apr2.111542@databs.enet.dec.com>
> 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.
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.
From: Jeff Dalton
Subject: Re: Lucid (Sun) Common Lisp vs Allegro (Franz) Common Lisp - the Summary
Date:
Message-ID: <4472@skye.ed.ac.uk>
In article <·····················@lexis.Princeton.EDU> ········@clarity.Princeton.EDU (Tim Weinrich) writes:
>
> 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.
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.
> 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.
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.
>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.)
Franz is supposed to have a similar facility, but I don't see anything
about it in the 4.0 User Guide.
> 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.
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.
> 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.
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.
>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.
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.
> 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.
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.
> Out of six sources who commented on the tty debugger (including the
>Lucid employee, the Franz employee, myself, and the magazine article),
>all but one preferred the Lucid debugger. The one exception, the
>Franz employee, thought they were comparable. This does not include
>the few comments I got concerning window debuggers, which seemed too
>vague to summarize.
I found the Allegro tty debugger (Rel 3) very uninformative. This
is somewhat strange since I don't feel the same way about the debugger
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 CL, which is --- as far as I know --- a preprocessor to C;
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