commonlisp types

[Jon L White <jonl@lucid.com>]

re: [TYPE-SPECIFIER-P] I'd like to encourage you to make YOUR definition 
    explicit for us, as a starting point.

Well, what I can tell you in reasonable terms won't be that helpful. We
simpy hook in to the part of SUBTYPEP that has to resolve these questions,
and "catch" any signals about unrecognized types.  For symbols, the
question of a recognized type is fairly easy -- there's a list in CLtL
of some basic types, and then there's more basic types coming from
DEFSTRUCT, and finally there's "recursion" via DEFTYPE.  Can you think
of an easier answer for this?


re:     Anyone know of an implementation for which this fails?
    Yes, Symbolics.  You must have missed my query about any implementations
    for which it succeeds!  Any implementation which does source-rewriting
    to optimize TYPEP has to concern itself with this issue.  (The issue is the
    same as for doing INLINEing, but Symbolics fails to use the same mechanism
    for optimizations as it does for inlining.)

Lucid succeeds (and one or two others that I tried).  Oddly enough, Lucid
also "fails" to use the same mechanism for compiler optimizers as it does
for INLINEing -- and it gets the optimizations right, but certain cases
of lexical inlining screws wrong.


-- JonL --