Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-tgr!tgr!cottrell@nbs-vms.ARPA From: cottrell@nbs-vms.ARPA Newsgroups: net.lang.c Subject: No Such Thing Message-ID: <868@brl-tgr.ARPA> Date: Wed, 21-Aug-85 18:06:33 EDT Article-I.D.: brl-tgr.868 Posted: Wed Aug 21 18:06:33 1985 Date-Received: Sat, 24-Aug-85 17:23:42 EDT Sender: news@brl-tgr.ARPA Lines: 89 /* > > > 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 */ ------