[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: RWK@FUJI.ILA.Dialnet.Symbolics.COM
- Subject: commonlisp types
- From: Jon L White <email@example.com>
- Date: Sat, 7 Jan 89 00:52:38 PST
- Cc: jonl%lucid.com@Riverside.SCRC.Symbolics.Com, common-lisp%sail.stanford.edu@Riverside.SCRC.Symbolics.Com
- In-reply-to: Robert W. Kerns's message of Fri, 6 Jan 89 15:16 EST <19890106201603.1.RWK@CALVARY.ILA.Dialnet.Symbolics.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 --