Re: [Sbcl-devel] [Bug 1080440] [NEW] FUNCALLABLE-STANDARD-OBJECT deviates from CLOS MOP specification since 1.1.0

[Christophe R. <cs...@ca...>]

 status invalid
 done

Pascal Costanza <pc...@p-...> writes:

> Two characteristics of FUNCALLABLE-STANDARD-OBJECT have changed in SBCL
> 1.1.0 from previous versions.
>
> - The class precedence list of funcallable-standard-object (class-
> precedence-list (find-class 'funcallable-standard-object)) should return
> the classes STANDARD-OBJECT and FUNCTION in that order, but actually
> reverses them.

This has been documented (at
<http://www.sbcl.org/manual/#Metaobject-Protocol>) to be this way in
SBCL for a very long time indeed; AMOP and ANSI 1.4.4.5 conflict -- if
you follow AMOP and make STANDARD-OBJECT precede FUNCTION, your
GENERIC-FUNCTION CPL ends up having STANDARD-OBJECT before FUNCTION,
which ANSI 1.4.4.5 and ANSI 4.2.2 disallow.

> - FUNCALLABLE-STANDARD-OBJECT is not an instance of STANDARD-CLASS
> anymore, although it is specified to be such. (typep (find-class
> 'funcallable-standard-object) (find-class 'standard-class)) should
> return T, not NIL.

This, also, has been documented to be this way for a very long time at
the same location.  The issue is in the consistency requirement that we
impose: something which is funcallable must
  - be TYPEP FUNCTION;
  - have a type which is SUBTYPEP FUNCTION;
  - be an instance of a class which has FUNCTION in its CPL.
(I think its clear that all of these are desireable requirements).

The low-level representation used in SBCL is such that funcallable
things have a distinct representation from non-funcallable things; under
that representation, we impose an extra requirement, that
FUNCALLABLE-STANDARD-CLASS objects have FUNCTION in their CPL (and
STANDARD-CLASS objects do not).  This provides consistency with the
low-level representation.

So, those are my explanations for the deviations.  The questions I have
are: firstly, I think these have been the way that they are for years (I
want to say "decades" but that's not quite true :-) -- so what makes you
think that this is a new thing?  Secondly, does this matter -- is this
affecting real code, or is this a proactive addition to
mop-tests/closer?  The way things were before (i.e. when SBCL didn't
deviate from AMOP in these ways) it was fairly easy to construct code
which in the first case found the discrepancy with ANSI, and in the
second case constructed funcallable things which were not typep FUNCTION
and/or things which were typep FUNCTION but not funcallable.

Cheers,

Christophe