[Openmcl-devel] New (030715) 0.14 binaries

[Gary Byers]

A source archive, these release notes, and Darwin binaries are now in
the testing directory on clozure.com  (<ftp://clozure.com/pub/testing/>);
LinuxPPC binaries should be there in an hour or two.

Changes since 030707:

Symbols are hashed (in all cases) baased on the characters in their pnames;
using their pnames works better than using N random bytes that happened
to be near the symbols themselves in memory (and could change over time.)
Somewhat amazingly, the only symptom of this bug that I saw or heard
reported was that a condition class name (CCL::COMPILER-FUNCTION-OVERFLOW)
wasn't recognized as a type specifier; it could/should have been a lot
worse.

The biggest change in functionality (and it's an admittedly minor change)
had to do with how DESTRUCTURING-BIND (and the destructuring done by things
like DEFMACRO and DEFTYPE) is implemented.  Traditionally in MCL and OpenMCL,
DESTRUCTURING-BIND macroexpanded into the implementation-specific special
operator CCL::DEBIND; that generated some very compact but largely opaque
code which called assembly-language routines in the kernel to "spread" a list
onto the stack (and to handle keyword arguments, defaulting optional args,
etc.)

There were a number of reasons for wanting to change this (including the
fact that it's not kosher for a standard ANSI CL macro to expand into
an implementation-specific special form.)  There are a few user-visible
consequences of this change:

 - It's not binary-compatible with the old mechanism: the FASL version
   changed again.

 - DEFTYPE is supposed to differe from DEFMACRO only in that '* is used
   as the default value for optional and keyword arguments.  As such,
   it's now legal to use &ENVIRONMENT in the lambda list of DEFTYPE forms
   and the expansion functions generated by DEFTYPE accept and expect to
   be called with a (possibly null) lexical environment as a second
   argument.

 - The traditional CCL::DEBIND special form accepted NIL in contexts
   where a variable or sub-lambda list could appear, with semantics
   similar to those offered by LOOP's destructuring facilities.  That
   was a simple and concise way of consuming and ignoring some or all
   of the list being destructured against,  As I read the spec, it's
   more consistent (if less convenient) to treat NIL in those contexts
   as denoting an empty sub-lambda list.

In cases where destructuring fails, the error that's signalled is supposed
to be of type PROGRAM-ERROR.  That's not (yet) consistently true, but
there's generally more information available when those errors are detected
in lisp code than when they were detected in the guts of some assembly
code in the kernel.

The old assembly-based destructuring mechanism is still used in some
cases involving inlining and lambda application.  I'd like to phase it
out (for a variety of reasons) but have not yet done so.

This is all admittedly fairly mundane and these effects will probably
rarely be visible (modulo bugs.)  Hopefully, the next update will offer
some changes that're a little more visually stimulating.


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel