Proposal #7 Status: TYPE-SPECIFIER-P

[David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>]

    Date: Sun, 27 Jul 1986  21:44 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>


    Several people have proposed that this be restricted to take only
    symbols, since that is the most important use, and it becomes hard to
    specify exactly what things must be checked for correctness in the
    myriad of more complex cases.  (Speaking for myself, I favor this
    change.)  This is proposed in 7A below.

This restriction potentially removes some of its usefulness.  I can
imagine
	(defun typep (object type-specifier)
	  (assert (type-specifier-p type-specifier) (type-specifier)
		  "~S is not a valid type-specifier" type-specifier)
	  ...etc...)  
and therefore it can't be restricted to a symbol and indeed must do full
semantic checking of the type specifier to make sure it is OK.
Therefore, (type-specifier-p '(complex array array)) is legal and
returns NIL.

    If someone wants to argue in favor of handling the more complex
    type-specifiers as well, I would ask you to provide a specific and
    detailed proposal for exactly what things must be examined in each case.

It returns T if it is a meaningful second argument to TYPEP and NIL if
not.  Is that specific enough?

    It was also suggested that we do this by (TYPEP arg 'TYPE-SPECIFIER), but
    some opposition to this idea has also been expressed, on the grounds
    that TYPE-SPECIFIER is not really a type in the usual sense.  Also, if
    we did this, it would be awkward to restrict the argument to being a
    symbol.
    ---------------------------------------------------------------------------
    Proposl #7A: TYPE-SPECIFIER-P

    Proposed extension:

    Add a new function (TYPE-SPECIFIER-P arg), where ARG must be a symbol.
    If ARG is a valid type specifier, this returns T; else it returns NIL.
    Note that the use of DEFSTRUCT and DEFTYPE can change the behavior of
    TYPE-SPECIFIER-P over time.