[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A simple question
- To: Russ Smith <smith@nrl-aic.ARPA>
- Subject: Re: A simple question
- From: email@example.com
- Date: Fri, 24 Apr 87 22:53:47 -0800
- Cc: firstname.lastname@example.org
- In-reply-to: Your message of 23 Apr 1987 13:42:18 EST (Thu). <546201738/smith@nrl-aic>
- Posted-date: Fri, 24 Apr 87 22:53:47 -0800
Page 71 of CLtL resolves any ambiguity on page 73 when it says, "We say that
a predicate is true when it returns a non-nil value, and is false when it
returns nil..."; thus <wry grin> implementors are free to let an expression
like (null (null 'foo)) return GRAND_PIANO if they wish, but portability-
oriented programmers are _not_ free to assume anything but non-nilness in
the returned value.
Personally, NUMBERP is the one that bothers me: it would be so nice to get
back the argument if it is numeric, nil otherwise, but CLtL merely says that
the value will be "true" and this is all that one may safely assume. Saying,
as CLtL does, that (numberp x) is identical (as in three horizontal bars) to
(typep x 'number) even tends to _suggest_ that the value _will_ be strictly
T or nil, a loss in my opinion.
Thanks for bringing this up--rationalization of this issue may be worth
fighting for in the ANSI Common Lisp committee's "clean-up of Steele" phase.