On 18 Nov 2012, at 21:52, Christophe Rhodes <csr21@...> wrote:
> status invalid
> Pascal Costanza <pc@...> 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 184.108.40.206 conflict -- if
> you follow AMOP and make STANDARD-OBJECT precede FUNCTION, your
> GENERIC-FUNCTION CPL ends up having STANDARD-OBJECT before FUNCTION,
> which ANSI 220.127.116.11 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?
Sorry for the noise: I misread the output of my test suite. I'm getting rusty… :-}
> 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.
It doesn't matter. Nothing to see here.