boolean true and false values.

[Jeff Petkau]

Tony J Ibbs (Tibs) <tony at lsl.co.uk> wrote in message
news:000d01bfdc23$c8aefae0$f0c809c0 at lslp7o.lsl.co.uk...
> There seem to be two (equally valid, I hasten to add!) traditions of
> handling booleans in programming languages. The (arguably) most obvious is
> to have a discrete boolean type, and thus the logical operators return a
> result of that type, and so on. Algol based languages tend to take this
> approach, and I have always found it more natural (as a pedant).
>
> The other tradition is that used by (for instance) the various Lisp
> derivatives, which is to have "empty" quantities represent false, and
> everything else represent true. This has various practical benefits, and I
> hesitate to argue it is less "theoretically" good.
>
> A language designer has to choose one or the other. Language users then
get
> to grumble if they don't like it. But both are eminently respectable, with
a
> long history.

I think Scheme uses a third method--the special value #f is false,
everything else is true. (Python could use None for the purpose).
This is a nice method for a dynamically typed language,
especially in combination with short-circuiting 'and' and 'or' that
return the true value instead of 'true'.

    x = getfoozle() or some_default_value

Short and clear, but a bit dangerous in Python or Perl or CLisp,
since getfoozle() might return a meaningful value that happens
to be false. Or this:

.    while 1:
.        foo = readline()
.        if not foo: break
.        dostuff(foo)

This works because readline() always returns at least a newline
until EOF is reached. But if you switch to some other sequence
where empty strings can appear, oops.

Of course you shouldn't do that, but how many scripts out in
the wild do you think have that exact bug?

Picking-the-trivial-things-to-rant-about,
--Jeff