mkent@dewey.soe.berkeley.edu (Marty Kent) (05/19/88)
Is anyone out there doing anything with pcl (CLOS) under Allegro common lisp? I've recently gotten the sources from parcvax, and I'm interested in the possibility of rewriting a bunch of code I've done in Object Lisp, in pcl. (Got that?) One reason I'd like to do this is that I'd expect to get a substantial speed increase. The Allegro documentation says that Object Lisp is not to be expected to run at high speed, but what about the implementation of pcl? Since it's still in some kind of early state of development, what kind of performance can one expect from the current version? I'd be very interested to hear from anyone who's actually done any measured comparisons between the two systems. Another factor possibly in pcl's favor is that it's supposedly on the way to becoming a standard, while Object Lisp's future seems to be less than rosy... Do you feel pcl is in fact emerging as a standard like common lisp (I mean widely accepted like common lisp, not necessarily funky like common lisp :-) or are there other lisp object extension systems clearly "in the running?" I'd be interested in hearing from anyone with thoughtful stuff to say about these things. Marty Kent Sixth Sense Research and Development 415/642 0288 415/548 9129 MKent@dewey.soe.berkeley.edu {uwvax, decvax, inhp4}!ucbvax!mkent%dewey.soe.berkeley.edu Kent's heuristic: Look for it first where you'd most like to find it.
mcconnel@zodiac.ads.com (Chris McConnell) (05/20/88)
The current version of PCL is implementing most of the Common Lisp Object System (CLOS). This will be the Object Oriented Programming standard for Common Lisp. I believe it will be officially approved sometime in June. PCL is fairly portable. I plan to bring it up in Allegro in the next month. If you accept the most generic implementation, it should already run in Allegro. (In fact, it may even have optimizations already since Allegro is really Franz and it already runs in Franz.) There are numerous ways to get it to run faster on a given implementation, but modifying the PCL code requires a very good knowledge of Lisp. I have done a lot of it fixing bugs and adding features, and I can tell you that it is no picnic. I ran some benchmarks a while ago on a Symbolics and a Sun running Lucid. The speed was better than I thought it would be for an early and portable implementation. Creation is slow, but execution speed of generic functions is very good. (Some of this is due to the caching mechanism that makes more recent methods faster.) We developed an image understanding environment using it, so the speed can't be too slow! I have been working in CLOS for a year (> 25,000 lines), and I have to say that even in its presently incomplete state that I love it. I have worked extensively in Flavors, an in house system called SOPE and some in Smalltalk. CLOS is far and away my favorite. Multiple specializers are great, especially on normal Lisp objects. The spec takes great pains to make all of the hooks that are needed available and public while still allowing implementations to do all of the things that are required to make things run fast.
jas@cadre.dsl.PITTSBURGH.EDU (Jeffrey A. Sullivan) (05/20/88)
In article <24158@ucbvax.BERKELEY.EDU>, mkent@dewey.soe.berkeley.edu (Marty Kent) writes: > Another factor possibly in pcl's favor is that it's supposedly on the way to > becoming a standard, while Object Lisp's future seems to be less than rosy... > Do you feel pcl is in fact emerging as a standard like common lisp (I mean > widely accepted like common lisp, not necessarily funky like common lisp :-) > or are there other lisp object extension systems clearly "in the running?" > Well, PCL is migrating toward a full implementaiton of CLOS (the Common Lisp Object System), but it aint QUITE there yet. It is, however, quite usable. And very powerful. I know that there have been some optimizations in it (I read the code), but there are no broad-based ones, and I can not vouch for its speed. I am using PCL entirely in a project of mine, and haven't had any complaints, but I am not concerned with efficiency at this time. CLOS _is_ the standard OOPS for CL, so using it is no bad idea. There is no doubt that CLOS (of which PCL is slowly implemeting) is the only OOPS officially supported by CL, so don't worry. There is, however, a LOT of code to CLOS/PCL, and it takes quite a tot of memory, while OL doesn't. Note that OL's future is not so bad, Coral will almost definitely implement a copy of OL in CLOS (it's not too hard...) just for compatibility's sake. -- .......................................................................... Jeffrey Sullivan | University of Pittsburgh jas@cadre.dsl.pittsburgh.edu | Intelligent Systems Studies Program jasper@PittVMS.BITNET, jasst3@cisunx.UUCP | Graduate Student
gz@spt.entity.com (Gail Zacharias) (05/20/88)
In article <3978@zodiac.UUCP> mcconnel@ads.com (Chris McConnell) writes: >PCL is fairly portable. I plan to bring it up in Allegro in the next >month. If you accept the most generic implementation, it should >already run in Allegro. (In fact, it may even have optimizations >already since Allegro is really Franz and it already runs in Franz.) First, let me clear up something here. I believe the original question was about Allegro CL for the Mac (which is really Coral Common Lisp) not about Allegro CL for Unix (which is really Franz Extended Common Lisp). Franz conditionalizations would certainly not work in Coral or vice versa. The two implementations have nothing in common aside from the name they're being marketed under, and some marketing person deserves an eternity in hell for causing this confusion. Secondly, PCL has already been brought up under Coral Common Lisp, with all the usual optimizations that PCL allows for. See the "coral-low" file that comes with PCL. Finally, regarding the original question - Object Lisp in CCL is not very efficient as native object systems go, but it IS a native implementation and is faster than PCL. So you won't speed up your code in the short term by going to PCL. However, in the longer term, Coral will provide a native implementation of CLOS, which should be more efficient than Object Lisp (and in any case, Object Lisp will get even less efficient since we'll probably re-implement it as a compatibility package on top of CLOS). So whether you decide to switch now depends on the relative importance of short-term vs long-term to you... One possibility is to stay with Object Lisp but adapt a coding style which doesn't take advantage of its special features, so as to make future conversion easier (e.g. maintain a strict distinction between classes and instances, don't create new instance variables on the fly, etc.). -- gz@entity.com ...!mit-eddie!gz Now let's all repeat the non-conformist oath.
bzs@bu-cs.BU.EDU (Barry Shein) (05/30/88)
I've been using PCL (and CLX) a lot lately under KCL on my Encores and Suns here. I like PCL, it seems to be a very clean design for an object-oriented set of tools for common lisp, fits into the language design well. The only thing I miss is a user's manual tho I assume that one is in progress, the supplied documentation tends to read more like an academic paper justifying its features (the supplied reference manual is ok, but it often just refers back to the first part. Anyhow, the hard part of mastering something like PCL is not understanding what the pieces do (at least not for me) but understanding how they are expected to be used together (nothing deep here, some clever, extensive, annotated examples might fill the gap.) At any rate, well done! -Barry Shein, Boston University