[closer-devel] Re: using a custom unbound slot marker

[Nikodemus Siivola]

Pascal Costanza <pc at p-cos.net> writes:

> Unfortunately, clisp is allowed to check this. The CLOS MOP spec
> states that the results are undefined if the restrictions on
> standard-instance-access are not met. One of the restrictions is
> that the slot must be bound for standard-instance-access to work.
> The HyperSpec states that "consequences are undefined" means that
> "conforming code must treat the consequences as unpredictable."
> Specifically, "an implementation is permitted to signal an error in
> this case."

More generally, implementation are essentially allowed to crash, burn
your house, and hose your data when you hit "undefined consequences".

_Unspecified_ consequences are the "harmless, but eg. an error"
territory.

> I think this is a case where the authors of the CLOS MOP
> specification weren't careful enough. On the one hand, they say that
> standard-instance-access "is intended to provide highly optimized
> access", but on the other hand, the wording "the results are
> undefined" leaves too much room for implementations. Other
> indications that the authors were a little bit too careless are that
> they haven't specified the respective setf function, and they also
> haven't specified accessors for slots with :allocation :class, which
> makes some implementors decide to add this "feature" to
> standard-instance-access as well.

Other similar oopses elsewhere:

* set-funcallable-instance-fun, but no funcallable-instance-fun

* slot-readers &co return _names_, not function object, which really
  sucks if the symbol has been eg. uninterned or fmakunbound, as that
  leaves you without any defined means to get at the generic function.

(Just in case someone is collecting these...)

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."