[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Jon L White <jonl%lucid.com@Riverside.SCRC.Symbolics.Com>
- Subject: commonlisp types
- From: Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
- Date: Fri, 6 Jan 89 15:16 EST
- Cc: common-lisp%sail.stanford.edu@Riverside.SCRC.Symbolics.Com
- In-reply-to: <8901040858.AA01403@bhopal>
Date: Wed, 4 Jan 89 00:58:57 PST
From: Jon L White <firstname.lastname@example.org>
re: How do you define "valid type specifier"?
Very syntactically. I think its perfectly acceptable to have a set
of combination rules for making "words" in the type-specifier syntax,
even though some such "words" would be gibberish.
The important thing is that base-level types -- those defined in
CLtL -- along with DEFSTRUCT extensions be recognizable. They don't
have the problems that SATISFIES generates, or that a broken user
definition generates (such as your DEFTYPE FOO example).
I'm not saying there's a fundamental problem here, just that there's a choice
to be made, and that writing precise and understandable definitions is
non-trivial. I'd like to encourage you to make YOUR definition explicit for
us, as a starting point.
By the bye, on another note, I haven't seen any implementation that
has the bug Kent wondered about earlier:
(defun bar (x) (symbolp x))
(defun foo (x)
(flet ((bar (y) (integerp y)))
(typep x '(satisfies bar))))
The correct answer is T, but I bet a lot of implementations return NIL
in compiled code.
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.)