[Openmcl-devel] Is this a bug?
gb at clozure.com
Sun Feb 10 14:43:41 PST 2008
In discussing how DEFCLASS is macroexpanded into something that
invokes ENSURE-CLASS (which will use ENSURE-CLASS-USING-CLASS to
either initialize or reinitialize an instance of the metaclass),
the MOP says (5.4.2, which runs on for a few pages):
The default initargs class option, if it is present in the defclass
form, becomes the value of the :direct-default-initargs keyword
argument to ensure-class. Special processing of this value is done to
properly capture the lexical scope of the default value forms. This is
done by converting each default initarg in the class option into a
canonicalized default initarg. The resulting list of canonicalized
default initargs is the value of the :direct-default-initargs keyword
argument to ensure-class.
On Sun, 10 Feb 2008, Ron Garret wrote:
> On Feb 9, 2008, at 6:21 PM, Gary Byers wrote:
>> The MOP says that DEFCLASS of an existing class uses
>> REINITIALIZE-INSTANCE to change that class (in-place), with initargs
>> derived from the defclass form.
> That's right. But even the MOP leaves a little wiggle room about whether an
> unspecified option in defclass necessarily leads to an unspecified keyword
> argument in the subsequent call to reinitialize-instance.
> From the description of DEFCLASS:
"... the arguments received by ENSURE-CLASS are derived from the
DEFCLASS form in a defined way." One of those defined ways is:
> "The default initargs class option, if it is present in the defclass form,
> becomes the value of the :direct-default-initargs keyword argument to
> But it doesn't actually say what happens if :default-initargs is not
> specified. There is room to interpret this as, "If default-initargs is not
> specified, then ensure-class is called with :direct-default-initargs
> specified as nil."
Ah. That would be the undefined way, then.
More information about the Openmcl-devel