[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
predicates for all type specifier symbols
- To: Daniels.PA@Xerox, NGALL@G.BBN.COM
- Subject: predicates for all type specifier symbols
- From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
- Date: Mon, 31 Mar 86 16:10 EST
- Cc: Common-Lisp@SU-AI
- In-reply-to: <860331-121028-4949@Xerox>
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. 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.
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.