Emilio Lopes <lopes.emilio@gmail.com> wrote:
+---------------
| > But remember, this is Common Lisp, not Scheme. In CL the *only*
| > distinguished boolean is NIL as "false" -- *everything* else is "true".
| 
| From R5RS, section 6.3.1 (Booleans):
|    Of all the standard Scheme values, only #f counts as false in
|    conditional expressions. Except for #f, all standard Scheme
|    values, including #t, pairs, the empty list, symbols, numbers,
|    strings, vectors, and procedures, count as true.
+---------------

Ouch! Sorry, and apologies to the Schemers. I said almost exactly
the inverse of what I meant. (*blush*)  What I was *trying* to say
is something like this: *Like* Scheme, in CL there is only one
distinguished boolean, namely NIL == "false", and *like* Scheme,
everything else is "true". Therefore there is no problem is using
the string one might get back from READ-LINE as a "true" truth value
[especially when one has done (READ-LINE stream NIL NIL) to guarantee
that EOF is "false"].

The only complication in CL is that, unlike Scheme, the sole "false"
boolean is *also* the empty list and is *also* an ordinary symbol,
whereas both of the latter two are always "true" in Scheme.

+---------------
| Also:
|    Welcome to scsh 0.6.6 (King Conan)
|    Type ,? for help.
|    > (if 42 'true 'false)
|    'true
|    >
+---------------

Yes, that works the same in both Scheme & CL. But in Scheme:

    (map not (map not (list #f '() 'nil)))
      ==> (#f #t #t)

whereas in CL:

    (mapcar #'not (mapcar #'not (list nil '() 'nil)))
      ==> (NIL NIL NIL)

Some see this as a good thing, some as bad. Different
languages, different styles, different communities.

Personally, now that I've been doing CL for a few years, I
*like* that fact that (EQ () NIL). On balance, it's more
convenience than confusion.

On the other hand, I *don't* especially like the fact that
(EQ 'NIL NIL) -- it requires some really bizarre contortions
in the internal implementation of CL, and even users get burned
by it once in a while [e.g., when trying to do symbolic processing
when the input comes from READ]. But I can live with it...


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607