PEP 285: Adding a bool type

[Huaiyu Zhu]

I don't think Guido follows this thread. I hope someone at least refer to
him Laura's and Alex' excellent articles.

Following is my $0.02 from algebraic point of view.

Several aspects need to be considered for a boolean type in a language:

- boolean objects (True, False)
- boolean algebra (and, or, not, xor, ...)
- boolean functionality (if, while, ...)
- IO representation

Python currently does not have boolean objects, but it has boolean-like
operators operating on all the objects.  The algebra is homomorphic to a
boolean algebra by the mapping operator.truth.  In other words,

	truth(a and b) == truth(a) and truth(b).

Similarly for 'or' and 'not'.  

The language structures that expects booleans accept all objects, and are
consistent with the truth mapping.  For example, if a <==> if truth(a).

It also happens that the range of operator.truth and 'not' consists of
integers 0, 1, but this is not necessary.

The operator truth divides all objects into two sets, those representing
nothing (mapped to 0) and those representing something (mapped to 1).  Under
this partition, we could regard the 'object' type as the boolean type,
except that equality based propositions do not work, such as

	not (a==b)  ==>  (a == not b).

This is one reason to introduce a boolean type (normalization). Another is
IO representation, which we will come to later.  There can be several
different ways to introduce a boolean type:

1. as a completely new and separate type, with strict and correct algebra.
2. as a subtype of int which is self contained with correct algebra.
3. as a new type with alternative printing methods, but automatically
   coerceable to integers, as normalization of boolean values.

The first two alternatives merely add new objects that could be classified
as "something" or "nothing".  They still need truth (or bool) to "normalize"
to booleans values.  They are both viable.  The first might be better if
booleans are equivalent to the partition of objects, so that we could say

	a in True
	b not in False

However, most of their benefits might be obtained by just having a few
builtins, such as truth, True and False.  The equality and IO problems are
solved using

	truth(a) == truth(b)
	print truth(a)
	a = False

Unfortunately, the proposal on the table is alternative 3, not just as
additional representations of booleans, but as normalization of booleans.
It is not consistent in the sense that it tries to normalize boolean values
without dropping the polymorphism of the boolean-like algebra and controls
structures.  It cannot solve the printing problem either because all the
true objects besides integer 1 would still be printed as themselves.

As Laura pointed out, making the distinction between something and nothing
(as opposed to true and false) is one of the reasons why well-written Python
programs are so elegant.  If we want to keep the polymorphism, ie. if we
want 'true' and 'false' to be representable by a great many objects, it is
futile to come up with an implicit printing solution for booleans.  Saying
print truth(a) is much more reliable and explicit and not much more
cumbersome.

Huaiyu