[gls: Proposal #7 amendment]

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

This proposal from Guy Steele looks good to me.  I think it checks a
reasonable amount of stuff and stops short of falling into the abyss.

-- Scott
---------------------------------------------------------------------------

Proposal #7 amendment

(1) First, not directly related to type specifiers, I propose a
primitive APPLICABLE that takes arguments just like APPLY, but rather
than actually doing the application it just returns T if the application
is okay with respect to argument-passing and NIL otherwise.  This can be
build on top of FUNCTION-PARAMETERS.

(2) I propose that there be primitives TYPE-EXPAND and TYPE-EXPAND-1 that
are similar to MACROEXPAND and MACROEXPAND-1 but operate on type specifiers.

(3) I propose that TYPE-SPECIFIER-P behave as follows:  if the argument
is a symbol, see whether it is a valid type specifier.  If the argument
is a list whose car is a symbol, then there are two cases.  If it is the
name of a primitive type specifier, then check the format of that type
specifier, using TYPE-SPECIFIER-P recursively where necessary.  If it is
the name of a DEFTYPE, then use APPLICABLE to be sure that the type
specifier expansion function is getting valid arguments.  If not, return
NIL; if so, then use TYPE-EXPAND-1 and recur on the result.  In summary,
TYPE-SPECIFIER-P will make sure a DEFTYPE'd specifier has approximately
the right format, but if the code in the specifier function ever signals
an error then TYPE-SPECIFIER-P won't catch that.