From: Pascal Costanza on
Hi,

I have just released a new version of Closer to MOP. This is a major new
release, with a couple of substantial improvements:

+ Support for Embeddable Common Lisp has been completely reworked, and
ECL is now officially supported in Closer to MOP (from ECL 9.12.2 on).

+ Macintosh Common Lisp has been reactivated as an open source project,
and the support for MCL in Closer to MOP has been resurrected.

+ Scieneer Common Lisp is now supported to some degree as well.

+ In total, Closer to MOP now supports 9 different Common Lisp
implementations: Allegro Common Lisp, CLisp, Clozure Common Lisp, CMU
Common Lisp, Embeddable Common Lisp, LispWorks, Macintosh Common Lisp,
Steel Bank Common Lisp, and Scieneer Common Lisp.

+ I have added support for the complete generic function invocation
protocol. This includes COMPUTE-APPLICABLE-METHODS,
COMPUTE-APPLICABLE-METHODS-USING-CLASSES,
COMPUTE-DISCRIMINATING-FUNCTION, and COMPUTE-EFFECTIVE-METHOD, and
MAKE-METHOD-LAMBDA (!). On top of that, Closer to MOP adds a missing
piece in the protocol, namely COMPUTE-EFFECTIVE-METHOD-FUNCTION, for
turning an effective method form into an actual function. Note, however,
that support for the generic invocation is not available in all
supported Common Lisp implementations: CMU Common Lisp, Macintosh Common
Lisp and Scieneer Common Lisp unfortunately don't provide the necessary
extensibility to support the protocols at all, and ECL has the slight
restriction that method lambda forms have the same lambda list as the
generic function for which they are defined, and not the format as
specified in AMOP.

+ In previous Closer to MOP versions, the standard metobject definition
macros and functions (DEFCLASS, DEFGENERIC, DEFMETHOD, ENSURE-CLASS,
ENSURE-GENERIC-FUNCTION, etc.) sometimes forced the use of the
replacement 'standard' metaobject classes of Closer to MOP
(STANDARD-CLASS, STANDARD-GENERIC-FUNCTION and STANDARD-METHOD). This is
now completely removed: If you don't use a :METACLASS or
:GENERIC-FUNCTION-CLASS option explicitly, these defining operators will
use the internal metaclasses of the respective Common Lisp
implementation, under the assumption that they are usually more
efficient than the replacements in Closer to MOP. If for some reason,
you want to ensure to use the replacements, you have to do so
explicitly. (Note: The main purpose of the replacements is to provide a
common compatible basis for your own metaobject subclasses, not to be
used in their own right.)

+ When synchronization is necessary, the code for Allegro Common Lisp
and LispWorks now uses constructs that are compatible with their
respective future SMP support.

+ In ECL and LispWorks, it is necessary to 'de-optimize' slot accesses
for the reader and writer methods specified in DEFCLASS forms in order
to ensure that SLOT-VALUE-USING-CLASS and (SETF SLOT-VALUE-USING-CLASS)
are correctly used. This now only happens if there are actually
applicable definitions available for them. Otherwise, they use the
native optimized slot access.

+ Extra special thanks to Duane Rettig, Steve Haflich, and Juan Jose
Garcia-Ripoll for fixing extra hard bugs in extra short amount of time.

For more information, see the Closer to MOP page at
http://common-lisp.net/project/closer/


Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/