Mark van Gulik raised the analogy of (car 'x) in Lisp.
I showed output from two Scheme systems and one Common Lisp system
(Macintosh CL implements Common Lisp, not Scheme) to show that this
hasn't been allowed for some time.

He asks:
	does (car '()) also fail, or simply answer ()?
	
In Scheme (which has been around for about 20 years), it is an error.
In Common Lisp, I'm sorry to say,
	"By definition, the car of () is (). ...
	 By definition, the cdr of () is ()."
The latter of these definitions *almost* makes sense, but I must say
the former makes no sense to me whatsoever.  This behaviour, where
CAR and CDR of NIL return NIL but are an error when applied to any
other atom goes back to Interlisp, at least 20 years ago.

	As an aside, I saw mention of a type deduction system for Scheme (based on
	the Mycroft-Milner algorithm if I recall) a few years back, but I don't know
	if it was introduced into the standard.  If it was, congratulations.
	
Henry Baker had a paper on a type inference algorithm for Common Lisp,
but it wasn't in the standard, and it wasn't _exactly_ the standard's
type system.  He gave reasons why the changes were necessary.	
	I'm aware that the minimalism of McCarthy's Lisp "avoided"
        explicit mention of booleans, but I'm not convinced it ever helped.

The question is not _whether_ it helped, but _what_ it helped.
Keeping your formalism minimal makes it easier to prove things about the
formalism itself, while at the same time making it harder to prove things
about specific formulas (because they get longer).

If anyone's really interested in such things, see the papers and books about
the Boyer-Moore theorem prover.

Certainly my own experience of converting Lisp to Scheme was that any
code that depended on the "pun" between '() and #f was already dangerously
obscure, and any code that depended on the "pun" between '() and NIL was
practically impossible to work with.

	[something bad] is like how C exposes
	the numeric representation of characters.

Very few programming languages try very hard to hide it, and given the
unspeakable number of built-in predicates and operations you would need
to manage without reasonably transparent mapping between characters and
codes, it is not clear to me that this is a bad thing.  Making characters
and numbers *identical* was clearly not the best idea, and it's one of the
ironies of design history that the one numeric type you *can't* use to
hold a character these days is 'char'.

	Only recently was there a standard bool type introduced
	into C++ (is it in the C standard yet?), and that *still* exposes
	the numeric representation.

Yes, it is in the C99 standard.  No, it *doesn't* expose the numeric
representation, it's just that whenever a _Bool value is (implicitly or
explicitly) **converted** to a number, the number you get is defined.	
But it's defined in Pascal and Ada too.  Heck, even in Eiffel, where
"true" and "false" are notionally objects, BOOLEAN.to_integer is
defined to give you 0 for false and 1 for true.