Re: Proposal #7 Status: TYPE-SPECIFIER-P

[Masinter.pa@Xerox.COM]

On some further thought,  TYPE-SPECIFIER-P is ambiguous in some cases
where the argument is a symbol: 

Suppose you have

(deftype relatively-prime-to (n) `(satisfies (lambda (x) (= 1 (gcd x
,n)))))

In this case, relatively-prime-to by itself is not "a valid type
specifier". 
(relatively-prime-to 10) is a valid type specifier, and
(relatively-prime-to t) is not.
Is the intent "is this something I can hand to typep?" If so, it would
be false for "relatively-prime-to". If the intent is "does this *name* a
type-specifier" then we could allow it, but the usefulness of such a
thing is unclear to me.

If the notion is "does this symbol name a class of Common Lisp objects,"
there may be a better way to get at this (e.g., CommonLoops defines
classes and it makes sense to ask, is there a class with this name).

With all of that, I'd argue against adding this, at this time, for the
following reasons:

a) it doesn't have well defined semantics, and attempts to narrow the
range in order to avoid ambiguity haven't succeeded

b) no one has offered a prototypical implementation, or even suggested
that they had an implementation for their common lisp against which we
could measure its use

c)  this is a request for a feature, but there's little evidence that
there are significant, meaningful, portable uses for it. (Portable = a
program written with one Common Lisp's version is likely to run with
another Common Lisp's version.)

d) of all of the proposals to consider, proposals to add new constructs
should get much lower priority than those to clarify or standardize
current constructs.

e) there is another proposal (before the Object Oriented Programming
committee in this case) which satisfies  at least part of the original
requirement in a different way.