Christophe Rhodes <csr21@...> writes:
> Nicolas Neuss <Nicolas.Neuss@...> writes:
> > Such type declarations should probably only be used (when compiling FROB)
> > if the generic function has been declared sealed. BTW, were Gerd
> > Moellmann's PCL improvements ported to SBCL?
> Gerd's PCL improvements come in (loosely categorized) three flavours
> (please correct me, Gerd, if I mischaracterize this):
> * code enhancements that were ported from SBCL when Gerd first
> started working on the PCL codebase;
> * CLOS and MOP conformance fixes;
> * performance improvements.
> Of these, clearly the first set of changes have not been ported to
> SBCL, because, well, we were there first :-) The second set have
> largely been ported (or developed in collaboration); there remains an
> exception in CALL-NEXT-METHOD and error checking with respect to
> arguments not being of the right type; the cmucl fix could trivially
> be ported, but it's a very expensive check and it's not clear that the
> ANSI standardizers meant what they said.
> As for the third category, which I suspect is perhaps the main thrust
> of your question (though, I dunno, I value quite highly the fact that
> our CLOS and MOP are mostly conforming): the answer is "partially".
> We have a fast implementation of MAKE-INSTANCE due to Gerd, and
> reasonable inlining of SLOT-VALUE/(SETF SLOT-VALUE)/SLOT-BOUNDP. We
> do not have accessor inlining, method call inlining or sealed class
Point 1 was probably getting rid of ITERATE, which was helpful for
understanding PCL's implementation. Alas, there wasn't much to port;
the code bases were already so different that it was faster to
do that mechanical transformation from scratch :/.
For the rest of my PCL changes, I must confess that I don't know for
sure what's in SBCL and what isn't. The only thing I'm 99% sure of is
that the PCL::CLASS vs. CL:CLASS dichotomy has been removed from SBCL
as well, which is probably the most important fix of all.
Maybe it's helpful if I list what might be missing In the new features
department (with all disclaimers because I didn't have the time to
check carefully)? Maybe that motivates some brave man or woman to
port some stuff:
I think SBCL has:
-- Ctor optimization of MAKE-INSTANCE. (The ctor.lisp in both PCLs
look quite different, though, and I don't know what version SBCL's
corresponds to. I'm mentioning this because ISTR fixing a couple
of bugs there over time.)
-- SLOT-VALUE optimization outside of methods
SBCL probably doesn't have:
-- Slot accessor gf-call pv optimization (like SLOT-VALUE in methods)
-- General gf-call optimization in methods
-- Slot type checking
-- "Inline" slot access (with or without auto method recompilation)
-- Inlining method functions in emfs. (I think I could also
do inlining of emfs in methods, but I either need to get very bored
or funded to do that :)).
-- Sealing. Might not be worth it, dunno. It's orthogonal to
optimizations being performed.
-- AMOP metaclass hierarchy (METAOBJECT)
-- Method tracing. Porting fwrappers from CMUCL, and using it for
TRACE/PROFILE would probably be helpful.
-- Quite some code cleanups/rewrites that were intertwined with other