commonlisp types

[Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>]

    Date: Wed, 4 Jan 89 00:58:57 PST
    From: Jon L White <jonl@lucid.com>

    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))))
	 (foo 'x)
	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.)