cottrell@nbs-vms.ARPA (08/22/85)
/* > > > I personally prefer to distinguish between Boolean > > > expressions (such as comparisons) and arithmetic expressions, using > > > strictly Boolean expressions as conditions. Thus: > > > while ( *s++ != '\0' ) > > > While I certainly agree that code should be written > > so that it is readible, I do not see how the relational operators > > in the above examples really improve the readibility of the code. > > Perhaps I can make this point clearer. Nearly all Algol-like > languages have a separate Boolean data type, and their conditional > expressions are required to be of Boolean type. In C, arithmetic > expressions are made to do double duty and are interpreted in > Boolean contexts as "true" if and only if the value is nonzero. Quit while you're ahead, Doug. > While this kludge obviously works, I think it adds one extra level > of mental processing when one is reading conditionals in C. This > is because there is no visible percept corresponding to one's > thoughts about comparison against zero; one has to explicitly apply > a conceptual language evaluation rule to map the expression into a > condition in order to extract the full meaning of the condition. Flame On! THERE IS NO SUCH THING AS A BOOLEAN!!! Flame Off. In case you hadn't noticed, `<' & company are infix operator that return a constant `zero' or `one'. Thus, *every* conditional using the `boolean' operators ultimately reduces to either if (0) { ... } or if (1) { ... } THIS IS NOT A KLUDGE! It is the WAY IT SHOULD BE! What could be more mnemonic (except to a nihilist :-) than TRUE if nonzero, and FALSE if zero. One of C's design virtues is that it is minimal, yet (relatively) complete. Don't drag outmoded concepts into the future! > Many Boolean expressions are not best thought of as comparison of > an arithmetic quantity against zero. For example: > while ( ! Done() ) > Perform_Action(); We agree, but for different reasons. You insist on dragging in an outmoded concept, then complaining that it doesn't fit very well. I just read what it says. > I have found that introducing Booleans as an explicit data type > into my C code has helped me produce better-organized code having > clearer meaning (once you get used to the idea). Although these > days... Context provided for below statement. > I am pretty conservative I think this pretty much sums it up. > ... when it comes to defining one's own > language extensions, this one seems like a winner: > > typedef int bool; > #define false 0 > #define true 1 > Seems like a loser to me. Just takes up space. I actually have to READ it. > And of course I can still read idiomatic C code produced by others, > but I do notice the extra effort required. Yeah, but then you go messing up your source with all those casts :-) > > Readible code is code where the authors intent is clear, where > > the data structures and the types of operations that can be > > performed on the data structures make sense in the context of the > > problem being solved. > > This is an excellent point. Perhaps I shouldn't be taking that > for granted. Actually, Doug, I'm not so much writing this to you as much as all those other people out there who insist on fortrash as a model for all their computing. Sorry about the cheap shot, but I wish you were a little more daring in your philosophy. K & R were. "Life is either a daring adventure, or nothing at all" - Helen Keller jim cottrell@nbs */ ------
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (08/23/85)
> Flame On! THERE IS NO SUCH THING AS A BOOLEAN!!! Flame Off.
There is no such thing as an integer, either. So what.
Booleans are not an "outmoded concept". They form a different
algebraic system (a lattice) than real numbers (a field) and
have different uses, both conceptually and formally.
I object to mapping everything into arithmetic terms.
Not everything in the universe is arithmetic.
I don't understand the point of explaining how C maps
natural booleans into arithmetic terms; that is just
what I am complaining about.mwm@ucbopal.CC (08/24/85)
From: Mike (I'll be mellow when I'm dead) Meyer <mwm@ucbopal.CC> I have avoided posting (for the most part) recently, but: In 868@brl-tgr.ARPA jim cottrell (cottrell@nbs-vms.ARPA) says: > Flame On! THERE IS NO SUCH THING AS A BOOLEAN!!! Flame Off. :-) Ok, we now know that jim doesn't believe in true and false. Does he drop right and wrong at the same time? How about write and read? :-) > In case you hadn't noticed, `<' & company are infix operator that > return a constant `zero' or `one'. Thus, *every* conditional using > the `boolean' operators ultimately reduces to either > if (0) { ... } or if (1) { ... } > THIS IS NOT A KLUDGE! It is the WAY IT SHOULD BE! What could be > more mnemonic (except to a nihilist :-) than TRUE if nonzero, and > FALSE if zero. One of C's design virtues is that it is minimal, yet > (relatively) complete. Don't drag outmoded concepts into the future! TRUE if nonzero, FALSE if zero? Sounds like jim just built a map from the set of C integers to booleans. But booleans don't exist, so such a map can't exist. Maybe what jim meant was: if (expression) { ... } is the same as: if expression is non-zero then { ... }. BTW, for something more mnemonic that 0 -> FALSE, {x | x /= 0} -> TRUE, how about nil -> FALSE, {x | x /= nil} -> TRUE, or {x | x = 0 mod 2} -> TRUE, {x | x = 1 mod 2} -> FALSE? Second BTW: C is not minimal. It's not bad, but there a half-dozen or so languages that have fewer operators, and equivalent completeness. Most of those are harder to use than C, though. > > Many Boolean expressions are not best thought of as comparison of > > an arithmetic quantity against zero. For example: > > while ( ! Done() ) > > Perform_Action(); > > We agree, but for different reasons. You insist on dragging in > an outmoded concept, then complaining that it doesn't fit very well. > I just read what it says. Sorry, but you've got it backwards. He's trying to pull a modern concept (TRUTH :-) into an obsolete language. Of course, if your language is nothing more than a high-level assembler, then using the funny "zero is false" map is ok, providing the underlying hardware doesn't provide a boolean type of it's own. > > I am pretty conservative > > I think this pretty much sums it up. Yeah - somebody who expects the programming languages to make their job easier is pretty conservative. I'm that way to - I want a language that makes it easy to turn my thoughts into code. This is why I prefer ALGOLW or C to FORTRAN or BASIC, and CLU or LISP to ALGOLW or C. > Actually, Doug, I'm not so much writing this to you as much as > all those other people out there who insist on fortrash as a model > for all their computing. Sorry about the cheap shot, but I wish you > were a little more daring in your philosophy. K & R were. Sorry, but I can't resist: Jim, from where I stand, *you* insist on fortrash as a model for your computing. There are more similarities between C and fortrash than differences. The C "if x is zero then ..." reminds me of the fortrash arithmetic if. But further discussion belongs in net.lang.* <mike "Truth is variable." * disclaimer: I like C. It's easily the best language to come out of the early '70s I've seen. However, this does not imply that 1) it's perfect; or 2) there aren't better general purpose languages available.
DHowell.ES@Xerox.ARPA (08/26/85)
The '_'s in the preceding mesaage should have of course been '='s. This is what happens when all these languages decide to use different assignment operators. (The '_' is a left arrow on my keyboard, and is the assignment operator in Mesa.) Dan
DHowell.ES@Xerox.ARPA (08/26/85)
> > ... when it comes to defining one's own > > language extensions, this one seems like a winner: > > > > typedef int bool; > > #define false 0 > > #define true 1 > > > Seems like a loser to me. Just takes up space. I actually have to READ it. 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! :-) ) I think it is much easier to read things such as: done _ true; than: done _ 1; Of course, explanatory comments in any case improves readability even more. Dan
barmar@mit-eddie.UUCP (Barry Margolin) (08/27/85)
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> ;
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@MIT-Multics
UUCP: ..!genrad!mit-eddie!barmarkjm@ut-ngp.UTEXAS (Ken Montgomery) (08/27/85)
From: barmar@mit-eddie.UUCP (Barry Margolin) >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. Not to me, at least. I write nearly nothing but assembler code (using a UNIX fullscreen editor I wrote, in C). I have no trouble going between C and assembler. In assembler, truth is what you make it. :-) > [...] No such memory is needed for the >assembler, of course, since comparison is merely done by subtraction, > [...] 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. All of my flag variables in assembler are 'true' when non-zero. I prefer this convention because the obvious 'true' value when working with packed flag fields is 1. Also, I'm no great fan of doing negative logic in software, which is what you get when you make 'true' be 0. >-- > Barry Margolin > ARPA: barmar@MIT-Multics > UUCP: ..!genrad!mit-eddie!barmar -- The above viewpoints are mine. They are unrelated to those of anyone else, including my cat and my employer. Ken Montgomery "Shredder-of-hapless-smurfs" ...!{ihnp4,allegra,seismo!ut-sally}!ut-ngp!kjm [Usenet, when working] kjm@ngp.{UTEXAS.EDU, ARPA} [Pick one. It might work.]
cottrell@nbs-vms.ARPA (COTTRELL, JAMES) (08/29/85)
/* > From: Mike (I'll be mellow when I'm dead) Meyer <mwm@ucbopal.CC> That's MY slogan too. > In 868@brl-tgr.ARPA jim cottrell (cottrell@nbs-vms.ARPA) says: > > Flame On! THERE IS NO SUCH THING AS A BOOLEAN!!! Flame Off. > > :-) Ok, we now know that jim doesn't believe in true and false. Does > he drop right and wrong at the same time? How about write and read? :-) Cute. > > In case you hadn't noticed, `<' & company are infix operator that > > return a constant `zero' or `one'. Thus, *every* conditional using > > the `boolean' operators ultimately reduces to either > > if (0) { ... } or if (1) { ... } > > THIS IS NOT A KLUDGE! It is the WAY IT SHOULD BE! What could be > > more mnemonic (except to a nihilist :-) than TRUE if nonzero, and > > FALSE if zero. One of C's design virtues is that it is minimal, yet > > (relatively) complete. Don't drag outmoded concepts into the future! > > TRUE if nonzero, FALSE if zero? Sounds like jim just built a map from > the set of C integers to booleans. But booleans don't exist, so such a > map can't exist. Maybe what jim meant was: > if (expression) { ... } > is the same as: > if expression is non-zero then { ... }. That's what the book says. > BTW, for something more mnemonic that > 0 -> FALSE, {x | x /= 0} -> TRUE, > how about > nil -> FALSE, {x | x /= nil} -> TRUE, or > {x | x = 0 mod 2} -> TRUE, {x | x = 1 mod 2} -> FALSE? As for the first, sounds like LISP. Are you proposing a funny predefined `thing' called `nil' that points to itself like in LISP? Will we have to cast all our tests to the proper type? As for the first, sounds like VAX Fortran. Since the VAX is little-endian, the low bit test words on all LOGICAL*[124] types. There have been all sorts of true-false mappings & conventions. Let's not forget using the sign bit. Anyway, to my mind, (& evidently to K&R) the use of zero to represent false is the most reasonable thing to do, if restricted to *in-band* values. When you ain't got nothin', you got nothin' to lose. > Second BTW: C is not minimal. It's not bad, but there a half-dozen or > so languages that have fewer operators, and equivalent completeness. > Most of those are harder to use than C, though. Okay. What I mean by minimal is that it includes only those features truly necessary to fully describe an idealized portable machine and which have meaning to the compiler. There is no exponentiation because few (if any) machines have it as a primitive. There is no repeat-until statement because that is a trivial variation of a while. There is no I/O, sets, booleans, complex numbers, or inline functions (except sizeof) that most other general purpose languages have. > > > Many Boolean expressions are not best thought of as comparison of > > > an arithmetic quantity against zero. For example: > > > while ( ! Done() ) > > > Perform_Action(); > > > > We agree, but for different reasons. You insist on dragging in > > an outmoded concept, then complaining that it doesn't fit very well. > > I just read what it says. > > Sorry, but you've got it backwards. He's trying to pull a modern > concept (TRUTH :-) into an obsolete language. Of course, if your > language is nothing more than a high-level assembler, then using the > funny "zero is false" map is ok, providing the underlying hardware > doesn't provide a boolean type of it's own. Like What? Zero is the most unique & important constant in the universe! All (or 99.99%) machines have a branch on (non)zero & some even have clear instruxions. > > > I am pretty conservative > > > > I think this pretty much sums it up. > > Yeah - somebody who expects the programming languages to make their > job easier is pretty conservative. I'm that way to - I want a language > that makes it easy to turn my thoughts into code. This is why I prefer > ALGOLW or C to FORTRAN or BASIC, and CLU or LISP to ALGOLW or C. Why do you keep putting a `W' on the end of `ALGOL'? I haven't a CLU :-) > > Actually, Doug, I'm not so much writing this to you as much as > > all those other people out there who insist on fortrash as a model > > for all their computing. Sorry about the cheap shot, but I wish you > > were a little more daring in your philosophy. K & R were. > > Sorry, but I can't resist: Jim, from where I stand, *you* insist on > fortrash as a model for your computing. There are more similarities > between C and fortrash than differences. The C "if x is zero then ..." > reminds me of the fortrash arithmetic if. But further discussion > belongs in net.lang.* Twisting things around a bit aren't we? I never even used the arithmatic if except when I was a freshman & thought it was cute. There are two main features of a language as I see it: 1) control struxures, & 2) data struxures. Fortran 77 has matured somewhat in the former, but leaves a lot to be desired in the latter. > <mike > > "Truth is variable." > > * disclaimer: I like C. It's easily the best language to come out of > the early '70s I've seen. However, this does not imply that 1) it's > perfect; or 2) there aren't better general purpose languages > available. 1) Agreed. I have criticized C as well in this very forum. 2) Maybe so. But *widely* available? jim cottrell@nbs */ ------
cottrell@nbs-vms.ARPA (COTTRELL, JAMES) (08/30/85)
/* > I don't understand the point of explaining how C maps > natural booleans into arithmetic terms; that is just > what I am complaining about. Does anyone else besides Gwyn have trouble with mapping booleans to integers? (Sorry Doug, I just couldn't resist :-) jim cottrell@nbs */ ------
darryl@ISM780.UUCP (08/30/85)
>To me, the mapping TRUE -> 0 and FALSE -> non-zero doesn't seem obvious, That's probably because you have it turned around... TRUE -> nonzero, FALSE -> 0. >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> ; Once again, you seemed slightly confused... These two don't exactly match each other. In assembler, you probably jump around the <do stuff> code. If you do, then you want to jump on nonzero, assuming the C code is what you really wanted. In any event, C's approach is very assembler-like; any conditional has an implicit comparison against zero, just like most machines support. >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. If you don't feel comfortable with a language, use another or spend the time and effort to become comfortable. C is certainly not my choice for a beauty contest, but one can craft large, useful programs that can then be run, reasonably efficiently, on many machines. I suppose that there is some beauty to that, after all. --Darryl Richman, INTERACTIVE Systems Corp. ...!cca!ima!ism780!darryl The views expressed above are my opinions only.
dmh@dicomed.UUCP (Dave Hollander) (09/16/85)
In article <1116@brl-tgr.ARPA> cottrell@nbs-vms.ARPA (COTTRELL, JAMES) writes: > >Does anyone else besides Gwyn have trouble with mapping booleans to integers? >(Sorry Doug, I just couldn't resist :-) > > jim cottrell@nbs >*/ >------ not any more - i have a big sign over my desk. dave