[closer-announce] New release of Closer to MOP (v0.6)

[Pascal Costanza]

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.


Pascal

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel
Software Languages Lab
Pleinlaan 2, B-1050 Brussel, Belgium