weinrich@clarity.Princeton.EDU (Tim Weinrich) (03/22/91)
Has anyone had a chance to compare Lucid Common Lisp to Allegro Common Lisp running on a Sun 3 or 4? I need to know people's impressions of the advantages/drawbacks of the two dialects wrt each other. I have only a minimal interest in speed comparisons. I am much more interested in people's experiences with things like the following: - Difficulties in translating existing Lisp code (not necessarily Common Lisp) to Lucid or Allegro. - Bugs - situations in which the implementation is clearly contrary to Steele. - Things you needed to do and couldnt, even if Steele doesnt require it. (Things like ERRSETs and communication with Unix/other programs, perhaps.) - The company's responsiveness to questions and bug reports. - Difficulties in compilation. - Preferences in debuggers. I am happy to receive responses from people affiliated with one of the companies, as long as you identify yourself as such. Perhaps someone has already posted a comparison of these Lisps and I missed the discussion. (I was away for a while.) If so, could someone forward me a copy? Reply directly to me and, if people are interested, I will post a compilation of the responses. Thanx! Twinerik
mahler@bruce.cs.monash.OZ.AU (Daniel Mahler) (03/25/91)
I am currently looking into the same question, so please post summary. This discussion must have occured before in this group. Does anyone remember when & is this discussion saved somewhere. daniel mahler
weinrich@clarity.Princeton.EDU (Tim Weinrich) (04/02/91)
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: carlson%franz%relay.EU.net@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: carlson@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,
barmar@think.com (Barry Margolin) (04/02/91)
In article <WEINRICH.91Apr1193134@lexis.Princeton.EDU> weinrich@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. barmar@think.com {uunet,harvard}!think!barmar
ballou@databs.enet.dec.com (04/03/91)
> 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.
jeff@aiai.ed.ac.uk (Jeff Dalton) (04/12/91)
In article <WEINRICH.91Apr1193134@lexis.Princeton.EDU> weinrich@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