Re: predicates for all type specifier symbols

[NGALL@G.BBN.COM]

    Date: Mon, 31 Mar 86 16:10 EST
    From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
    To: Daniels.PA@Xerox, NGALL@G.BBN.COM
    Subject: predicates for all type specifier symbols
    In-Reply-To: <860331-121028-4949@Xerox>
    Message-ID: <860331161012.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
    
    Actually, the TRUE and FALSE functions I asked for return the constant values
    true and false. The TP and NILP functions being proposed happen to constantly
    return true and false, respectively, but do not do so because they are directly 
    defined to do so; they do so because it is a logical consequence of the fact 
    that all things are of type T and no things are of type NIL. In addition to the
    number of args issues that Daniels pointed out, let me make it clear that I 
    would not be satisfied with these because code written to use them would not be
    perspicuous. 
You're right,
:TEST #'true
is more perspicuous than
:TEST #'tp
but I think
:CONDITION #'condition
is the most perspicuous.  So we don't need the function TRUE to reduce
visual clutter.

It would bother me as much as it bothered me to see code in Maclisp
    that did:
     (AND FOO
	  (NOT (TERPRI))
	  (PRINT MESSAGE)
	  ...)
    Sure, it was defined in Maclisp that TERPRI returned NIL and PRINT returned T
    but there are times when in spite of definition, it just isn't stylistically
    appropriate to take advantage of that fact in code that you would want to show 
    your mother.
I don't agree with your analogy to TERPRI.  The phrase
:TEST #'tp
means "whatever condition is handed to me is within the set of conditions
that I will deal with".  Granted its not as perspicuous as
:TEST #'conditionp
but its not as random as just using any always-true function.
    
    While I'm on the subject, let me point out that I consider completeness arguments
    for having all possible "-P" type predicates to be weak because it only reinforces
    the arbitrary line between system and user code. User-defined types are not 
    required to have such predicates, and even if they have them, the naming 
    conventions we defaultly assign do not match. If we required the fixing of the
    way predicates were constructed and removed the user's ability to either inhibit
    the definition of such predicates or choose an alternate name for such predicates,
    then we'd be making progress toward linguistic consistency. As it is, I think
    we're just gonna have to settle for the fact that the names that are there are
    there for convenience and not for any purist reason. Having accepted that, I
    don't see a lot of reason for introducing a lot of new predicates. If there were
    particulars that people had found immensely useful in a variety of circumstances,
    maybe we could consider adding them on a case-by-case basis. But let's not treat
    this as a class-action suit.

"Class-Action Suit" makes it sound like I'm asking for hundreds of new
predicates.  I'm asking for 13.

I doubt that all (even most of?) the existing predicates are
"immensely useful", so why should the few additional ones have to pass
such a test.  I would find some of them "useful", e.g., fixnump (I
didn't understand Moon's objection to this one), sequence, and
simple-array.

Also, I like the idea embodied in defstruct:  If someone defines a
type, chances are they would find a predicate useful.  I think the
same should apply to system defined types.

I guess you prefer the idea embodied in deftype, which does not define
an associated predicate.

	-- Nick