Xref: utzoo comp.lang.lisp:899 comp.sys.mac.programmer:885
Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ll-xn!mit-eddie!bloom-beacon!ht!spt!gz
From: gz@spt.entity.com (Gail Zacharias)
Newsgroups: comp.lang.lisp,comp.sys.mac.programmer
Subject: Re: Anyone using pcl (clos) under Allegro Common Lisp?
Message-ID: <306@spt.entity.com>
Date: 19 May 88 21:41:56 GMT
References: <24158@ucbvax.BERKELEY.EDU> <3978@zodiac.UUCP>
Reply-To: gz@eddie.mit.edu (Gail Zacharias)
Organization: A Kindof Entity, Cambridge, MA
Lines: 34

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.