Christophe Rhodes <csr21@...> writes:
> I propose the following freeze-busting patch for review: this problem
> was in 0.9.18, so strictly speaking it's not a regression, but it was
> not in 0.9.17. Comments, please.
> + #!+sb-eval
> + (compiled-function 'compiled-function)
Oh, but it gets worse.
STANDARD-GENERIC-FUNCTION is also one of the built-in-types of figure
4-2 that we must return a recognizeable subtype of if the object is
TYPEP it. (Please adjust the grammar).
(typep #'print-object 'standard-generic-function) => t
(subtypep (type-of #'print-object) 'standard-generic-function)
must return T, T.
Since generic functions are generally compiled, also
(subtypep (type-of #'print-object) 'compiled-function)
must return T, T. Additionally
must return something that
| does not involve and, eql, member, not, or, satisfies, or values.
-- CLHS TYPE-OF
At that point, I am stuck, because I can't construct a type specifier
that is subtypep both COMPILED-FUNCTION and STANDARD-GENERIC-FUNCTION
which doesn't involve AND or SATISFIES. So, alternatives:
* teach the system that STANDARD-GENERIC-FUNCTION is subtypep
COMPILED-FUNCTION. (Is it? I suppose it is, even if I turn
*EVALUATOR-MODE* on to :INTERPRET)
* fool the system into not thinking that STANDARD-GENERIC-FUNCTION
objects are COMPILED-FUNCTION-P.
I think the first one is probably right, in that the
SB-EVAL:INTERPRETED-FUNCTION probably can't get mixed into any other
funcallable instance type; it will probably be slightly tedious to get
this right in the type system, but it can be done. (Though not for