This Sentence is False

[COTTRELL, JAMES]

/* Fiercely I go into battle:
> I have always thought that to be a machine dependancy (the value of true and
> false).  Maybe I'm wrong.  But, different machines DO have different ideas
> of which is true and false (at the assembler level).  And it is simply
> a convention.

Machines have no concept of truth. They can determine if a condition
(equality, greater than, negative, overflow, etc.) exists and then
*dynamically* alter the course of their control flow. But no machine
I know of has a `branch if true' instruxion. Note I am not talking
about the abstraxion a la 68k where an unconditional branch is named
`branch if true' & the converse is called `branch if false'. I am 
talking about a *conditional* `branch if true'.
 
> Still though, #define TRUE (1==1) is very obvious, to the point, correct,
> proper, and all sorts of things.  And it doesn't require one to know
> that detail about C that the convention is ~0 == TRUE and 0 == FALSE.

Your attention span must be even shorter than mine. (What were we talking
about :-) If you are consistant, ignorance is bliss. But what about
fred's code over there, if (p). Hmmmm, now what does that do?

> But C gives you all these operators which allow you to define things
> machine independantly rather than hardcoding values.  Obviously I mean
> casts and the sizeof operator.  Also arithmetic to pointers.  So why not
> TRUE and FALSE?
> --- David Herron

Because who needs them? Integers do quit well, thank you.
On to my next victim.

> Not really.  You could usually safely assume that if someone is defining
> true and false, he/she is defining it as above.  (if some joker decides
> to define false as 29 and true as 53, he should be forced for eternity
> to covert 10,000-line APL programs to Fortran! :-) )

Agreed. But it's not 29 & 53 were talking about now is it? Zero & One
have certain useful mathematical properties, described below.

> I think it is much easier to read things such as:
>
>    done = true;
> 
> than:
> 
>    done = 1;

How about `done++'. Most variables are initialized to false. It's
kinda like reality, nothing can be taken for granted (default false)
unless it appears to be true.

> Of course, explanatory comments in any case improves readability even
> more.
> Dan Howell

Most definitely. Now for the last one:

> To me, the mapping TRUE -> 0 and FALSE -> non-zero doesn't seem obvious,
> and I'm sure it isn't to most programmers who ever worked in assembler.
> In assembler, one often writes the following (I'm using pseudocode
> rather than any particular assembler):
> 
> 	compare two values
> 	jumpto stuff  if zero
> 
> Which is the assembler equivalent of
> 
>         if (value1 == value2)
> 	  <do stuff> ;

I think you've got it backwards. 

> When I was in high school I was programming TRS-80's in both assembler
> and BASIC, and I had lots of trouble remembering whether BASIC
> represented truth as zero or -1.  No such memory is needed for the
> assembler, of course, since comparison is merely done by subtraction (a
> compare instruction is usually just a subtract instruction that doesn't
> store the result anywhere), so it is obvious what the zero indicator
> means.  It is not so obvious to me that in C 0 should mean false and 1
> mean true.
> -- 
>     Barry Margolin
>     ARPA: barmar at MIT-Multics
>     UUCP: ..!genrad!mit-eddie!barmar

Ah but it is! Consider the mathematical implications of it! The MAX
funxion is just the expression `(A > B) * A + (A < B) * B'. APL, which
was designed by a mathematician, uses the exact same concept. The
idea of `P implies Q' can be written as `P <= Q'! There have been many
different *conventions* used in many languages to represent the
*hidden* boolean values, sometimes differing between implementations.
I think time will show that APL & C do it the best way. At least the
cat's out of the bag & everybody knows what the spots look like.

	jim		cottrell at nbs
*/
------