www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 0.148 release

reply "Walter Bright" <newshound digitalmars.com> writes:
Lots of new stuff, I added new threads for them in the digitalmars.D 
newsgroup.

http://www.digitalmars.com/d/changelog.html
Feb 25 2006
next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright  
<newshound digitalmars.com> wrote:

 Lots of new stuff, I added new threads for them in the digitalmars.D
 newsgroup.

Well you almost got bool right <G> Everything except that it does implicit conversion to int. That is just a cheap cop out for lazy coding, IMNSHO. //-------------------- import std.stdio; void main() { bool a; bool b; bool c; bool d; int e; a = true; b = true; c = true; d = a + b + c; e = a + b + c; // In a decent implentation, this should have failed to compile writefln("%s %s %s %s %s", a,b,c,d,e); writefln("%d %d %d %d %d", a,b,c,d,e); // And this might have been a runtime error? } //------------------- -- Derek Parnell Melbourne, Australia
Feb 25 2006
next sibling parent reply Tom <Tom_member pathlink.com> writes:
In article <op.s5kaquba6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell says...
On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright  

[snip]
   d = a + b + c;

Sorry, how is the above different than the next?
   e = a + b + c; // In a decent implentation, this should have failed to  
 compile

I mean, in a decent implementation, would it be right to allow '+' (numeric add operator) between boolean vars? Regards, Tom;
Feb 25 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
On Sun, 26 Feb 2006 15:33:18 +1100, Tom <Tom_member pathlink.com> wrote:

 In article <op.s5kaquba6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell  
 says...
 On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright

[snip]
   d = a + b + c;

Sorry, how is the above different than the next?
   e = a + b + c; // In a decent implentation, this should have failed to
 compile

I mean, in a decent implementation, would it be right to allow '+' (numeric add operator) between boolean vars?

No it wouldn't either. I rushed my response as I was going out visiting my Dad - he turned 74 today. -- Derek Parnell Melbourne, Australia
Feb 25 2006
parent Tom <Tom_member pathlink.com> writes:
In article <op.s5kj5uym6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell says...
On Sun, 26 Feb 2006 15:33:18 +1100, Tom <Tom_member pathlink.com> wrote:

 In article <op.s5kaquba6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell  
 says...
 On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright

[snip]
   d = a + b + c;

Sorry, how is the above different than the next?
   e = a + b + c; // In a decent implentation, this should have failed to
 compile

I mean, in a decent implementation, would it be right to allow '+' (numeric add operator) between boolean vars?

No it wouldn't either. I rushed my response as I was going out visiting my Dad - he turned 74 today.

That's ok, i see. :-) Wish your dad a happy birthday. Regards, Tom;
Feb 26 2006
prev sibling parent reply Wang Zhen <nehzgnaw gmail.com> writes:
Derek Parnell wrote:
 On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright  
 <newshound digitalmars.com> wrote:
 
 Lots of new stuff, I added new threads for them in the digitalmars.D
 newsgroup.

Well you almost got bool right <G> Everything except that it does implicit conversion to int. That is just a cheap cop out for lazy coding, IMNSHO.

Pardon my ignorance, but why does D need a primitive type for booleans in the first place? What's wrong with "alias ubyte bool;" or "alias int bool;"? Can't we simply treat zero as false and non-zero as true as we C programmers always do?
 
 //--------------------
 import std.stdio;
 
 void main()
 {
   bool a;
   bool b;
   bool c;
   bool d;
   int e;
 
   a = true;
   b = true;
   c = true;
   d = a + b + c;
   e = a + b + c; // In a decent implentation, this should have failed 
 to  compile
   writefln("%s %s %s %s %s", a,b,c,d,e);
   writefln("%d %d %d %d %d", a,b,c,d,e); // And this might have been a  
 runtime error?
 
 }
 //-------------------

Feb 25 2006
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Wang Zhen wrote:
 Derek Parnell wrote:
 On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright  
 <newshound digitalmars.com> wrote:

 Lots of new stuff, I added new threads for them in the digitalmars.D
 newsgroup.

Well you almost got bool right <G> Everything except that it does implicit conversion to int. That is just a cheap cop out for lazy coding, IMNSHO.

Pardon my ignorance, but why does D need a primitive type for booleans in the first place? What's wrong with "alias ubyte bool;" or "alias int bool;"? Can't we simply treat zero as false and non-zero as true as we C programmers always do?
 //--------------------
 import std.stdio;

 void main()
 {
   bool a;
   bool b;
   bool c;
   bool d;
   int e;

   a = true;
   b = true;
   c = true;
   d = a + b + c;
   e = a + b + c; // In a decent implentation, this should have failed 
 to  compile
   writefln("%s %s %s %s %s", a,b,c,d,e);
   writefln("%d %d %d %d %d", a,b,c,d,e); // And this might have been 
 a  runtime error?

 }
 //-------------------


Because there exists a boolean type that has different contstraints than a normal integral type. In a good type system, these are enforced by the compiler with a builtin type. Search for Derek's post about it in the D NG.
Feb 25 2006
prev sibling next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Sun, 26 Feb 2006 17:29:03 +1100, Wang Zhen <nehzgnaw gmail.com> wrote:

 Derek Parnell wrote:
 On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright   
 <newshound digitalmars.com> wrote:

 Lots of new stuff, I added new threads for them in the digitalmars.D
 newsgroup.

implicit conversion to int. That is just a cheap cop out for lazy coding, IMNSHO.

Pardon my ignorance,

That's okay.
 but why does D need a primitive type for booleans in the first place?  
 What's wrong with "alias ubyte bool;" or "alias int bool;"?

The short answer is that booleans are not numbers. They represent truth and falsehood.
 Can't we simply treat zero as false and non-zero as true as we C  
 programmers always do?

*We* are not C programmers ;-) *We* have grown up from that baby-talk ;-) Zero is frequently used to implement the concept of falsehood and likewise non-zero for truth, however the semantics of integers is not the same as the semantics of booleans. But because many C programers are just *so* used to thinking this way they have become to believe that zero *is* falsehood rather than just a number chosen to implement the concept. It is quite possible for a language to implement falsehood/truth is ways other than using integers but even if they do, the compiler can still ensure that the sematics are adhered to rather than continue using integer sematics. The only thing I can see wrong with D's new boolean is that it still pretends its a number. Why is this wrong? Because it can lead to coding mistakes and abuse. Thus making maintenance more costly than it needed to be. Walter is still living in the C/C++ past with this concept, which is strange seeing he has implemented so many progressive concepts in D. Boolean as an integer is just retro. -- Derek Parnell Melbourne, Australia
Feb 25 2006
next sibling parent reply bobef <bobef lessequal.com> writes:
Derek Parnell wrote:
 
 Zero is frequently used to implement the concept of falsehood and 
 likewise non-zero for truth, however the semantics of integers is not 
 the same as the semantics of booleans. But because many C programers are 
 just *so* used to thinking this way they have become to believe that 
 zero *is* falsehood rather than just a number chosen to implement the 
 concept.
 

Just thoughts... Well back in school we were learning boolean algebra. (for some electrical crap... I don't remember... I don't care...). Even if we take just the name 'boolean algebra' it means it used for calculations, which means it is number not falsehood... After all it used for all these logical operators which operate with numbers not falsehood... If we say it is not calculations and it is logical operations, well it is not, else it would be only true, false, if a to b is false and c to b is true then a to c is ... this kind of stuff. But it is actually used for numbers and calculations, because 01101010<<0202 is not logic anymore it is mathematics which is also logic but other kind than true/false, logic for the quantity of things not their rightness... And one more thing. If it is falsehood indeed, then it is something abstract. Technically speaking True and False have any meaning only in the context of each other, i.e. in the context of some logic, system or whatever, not in the context of numbers. So how are you going to convert from number to falsehood? This would limit us to writing only bool a=true || bool a=false, which seems annoying to me. bool a=1 is shorter ;]. Plus there will be no if(a), if(b), because a is always true or always false by itself, it should relate to something else to be right or wrong, so we will always have to write if(a==1), if(b==null) instead, so I like it this way ;] Am I talking nonsese? :)
Feb 26 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
On Sun, 26 Feb 2006 19:39:48 +1100, bobef <bobef lessequal.com> wrote:

 Derek Parnell wrote:
  Zero is frequently used to implement the concept of falsehood and  
 likewise non-zero for truth, however the semantics of integers is not  
 the same as the semantics of booleans. But because many C programers  
 are just *so* used to thinking this way they have become to believe  
 that zero *is* falsehood rather than just a number chosen to implement  
 the concept.

Just thoughts... Well back in school we were learning boolean algebra. (for some electrical crap... I don't remember... I don't care...). Even if we take just the name 'boolean algebra' it means it used for calculations, which means it is number not falsehood...

Not so. It is possible to create 'calculations' using purely logic expressions. The result is not a number but one of 'false' or 'true' (or unknown). Fuzzy logic calulations are more of a numerical field (probablilty theory).
 After all it used for all these logical operators which operate with  
 numbers not falsehood...

Well I'm sure it operates on relationships between numbers and not the numbers themselves.
 If we say it is not calculations and it is logical operations, well it  
 is not, else it would be only true, false, if a to b is false and c to b  
 is true then a to c is ... this kind of stuff. But it is actually used  
 for numbers and calculations, because 01101010<<0202 is not logic  
 anymore it is mathematics which is also logic but other kind than  
 true/false, logic for the quantity of things not their rightness...

Ok whatever ... but I was talking about what one gets when one compares things with other things in relative terms or similar... e.g. a < b ==> true or false
 And one more thing. If it is falsehood indeed, then it is something  
 abstract. Technically speaking True and False have any meaning only in  
 the context of each other, i.e. in the context of some logic, system or  
 whatever, not in the context of numbers. So how are you going to convert  
 from number to falsehood?

By agreeing on a convention that is convenient.
 This would limit us to writing only bool a=true || bool a=false, which  
 seems annoying to me. bool a=1 is shorter ;].

Yes it is shorter, but it is not descriptive of your intention. Did you want 'a' to be set to 1 or to true? In other words, is the 'bool' a mistake and really meant 'int'? Because the use of 1 in this way is ambiguous it ought to be made cleaner / clearer to future maintainers.
 Plus there will be no if(a), if(b), because a is always true or always  
 false by itself, it should relate to something else to be right or  
 wrong, so we will always have to write if(a==1), if(b==null) instead, so  
 I like it this way ;]

I take the syntax form 'if (<numeric-expression>)' to just be shorthand for 'if (<numeric-expression> != 0)' and thus it would still be valid syntax and get you the result you were expecting. No relaxation of boolean sematrics is required.
 Am I talking nonsese? :)

No. -- Derek Parnell Melbourne, Australia
Feb 26 2006
parent bobef <bobef lessequal.com> writes:
Derek Parnell wrote:

 In other words, is the 'bool' a 
 mistake and really meant 'int'? Because the use of 1 in this way is 
 ambiguous it ought to be made cleaner / clearer to future maintainers.

I think this is the case. In programming when one says bool, he actually means int... So I believe making it real bool is something we don't need, because it works just fine this way. What we have to do (maybe, I don't need it personally) is to think of new name for a type which is true relative to non zero and false relative to zero... Then it will work with the current state of programming languages and will not conflict with the name bool. Although in computers many words are uses with different meaning... I don't know... I lost the original thought already...
Feb 26 2006
prev sibling next sibling parent reply Georg Wrede <georg nospam.org> writes:
Derek Parnell wrote:
 Walter is still living in the C/C++ past with this concept, which is  
 strange seeing he has implemented so many progressive concepts in D.  
 Boolean as an integer is just retro.

So am I. Booleans have to be int. A boolean may have any "numeric" value, but if implicitly cast to a numeric type, it should return 1 or 0. D IS A PRACTICAL PROGRAMMING LANGUAGE. Forcing booleans to be 1/0 all the way is just academic, purist, impractical bigotry. About as smart as having the bit type. (Besides, if booleans, as some say here, are _only_ abstract concepts, then we might as well decide to have 0 mean true and 1 mean false. Heh, there's only one truth but millions of lies! But we live in a world with other people. And computers.) Now, specifying 0 to mean false and everything else to mean not-false, we go along with the hardware, the computer industry, half a century of programming PRACTICE, and make life less difficult for anybody with a professional programming background before moving to D. Anybody who wants a tight-ass boolean, can define one for themselves. //// Now off to the Olympic Final in ice hockey: Finland - Sweden!!!
Feb 26 2006
next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Georg Wrede wrote:
 Derek Parnell wrote:
 Walter is still living in the C/C++ past with this concept, which is  
 strange seeing he has implemented so many progressive concepts in D.  
 Boolean as an integer is just retro.

So am I. Booleans have to be int. A boolean may have any "numeric" value, but if implicitly cast to a numeric type, it should return 1 or 0. D IS A PRACTICAL PROGRAMMING LANGUAGE. Forcing booleans to be 1/0 all the way is just academic, purist, impractical bigotry. About as smart as having the bit type. (Besides, if booleans, as some say here, are _only_ abstract concepts, then we might as well decide to have 0 mean true and 1 mean false. Heh, there's only one truth but millions of lies! But we live in a world with other people. And computers.) Now, specifying 0 to mean false and everything else to mean not-false, we go along with the hardware, the computer industry, half a century of programming PRACTICE, and make life less difficult for anybody with a professional programming background before moving to D. Anybody who wants a tight-ass boolean, can define one for themselves. //// Now off to the Olympic Final in ice hockey: Finland - Sweden!!!

How would having a builtin, "purist" boolean type preclude using integers as a boolean type, in all the old ways you describe? Just as a curiosity, how have you been burned in the past by "purist" thinking like this to make you so passionately against it?
Feb 26 2006
parent reply Tom <Tom_member pathlink.com> writes:
In article <dtsgbj$1h6u$3 digitaldaemon.com>, Kyle Furlong says...
Georg Wrede wrote:
 Derek Parnell wrote:
 Walter is still living in the C/C++ past with this concept, which is  
 strange seeing he has implemented so many progressive concepts in D.  
 Boolean as an integer is just retro.

So am I. Booleans have to be int. A boolean may have any "numeric" value, but if implicitly cast to a numeric type, it should return 1 or 0. D IS A PRACTICAL PROGRAMMING LANGUAGE. Forcing booleans to be 1/0 all the way is just academic, purist, impractical bigotry. About as smart as having the bit type. (Besides, if booleans, as some say here, are _only_ abstract concepts, then we might as well decide to have 0 mean true and 1 mean false. Heh, there's only one truth but millions of lies! But we live in a world with other people. And computers.) Now, specifying 0 to mean false and everything else to mean not-false, we go along with the hardware, the computer industry, half a century of programming PRACTICE, and make life less difficult for anybody with a professional programming background before moving to D. Anybody who wants a tight-ass boolean, can define one for themselves. //// Now off to the Olympic Final in ice hockey: Finland - Sweden!!!

How would having a builtin, "purist" boolean type preclude using integers as a boolean type, in all the old ways you describe? Just as a curiosity, how have you been burned in the past by "purist" thinking like this to make you so passionately against it?

I'd like to hear the answer :) . Have to stay at the purists side on this one. I like bool to be bool cause I'm that kind of guy that can't tolerate inconsistence (however I do tolerate it cause don't have much of a choice right now) and I'm putting all my hope in D. However both (the purist and the pragmatic) ways could coexist in the same language I guess. Tom;
Feb 26 2006
next sibling parent reply Wang Zhen <nehzgnaw gmail.com> writes:
Tom wrote:
 In article <dtsgbj$1h6u$3 digitaldaemon.com>, Kyle Furlong says...
 
Georg Wrede wrote:

Derek Parnell wrote:

Walter is still living in the C/C++ past with this concept, which is  
strange seeing he has implemented so many progressive concepts in D.  
Boolean as an integer is just retro.

So am I. Booleans have to be int. A boolean may have any "numeric" value, but if implicitly cast to a numeric type, it should return 1 or 0. D IS A PRACTICAL PROGRAMMING LANGUAGE. Forcing booleans to be 1/0 all the way is just academic, purist, impractical bigotry. About as smart as having the bit type. (Besides, if booleans, as some say here, are _only_ abstract concepts, then we might as well decide to have 0 mean true and 1 mean false. Heh, there's only one truth but millions of lies! But we live in a world with other people. And computers.) Now, specifying 0 to mean false and everything else to mean not-false, we go along with the hardware, the computer industry, half a century of programming PRACTICE, and make life less difficult for anybody with a professional programming background before moving to D. Anybody who wants a tight-ass boolean, can define one for themselves. //// Now off to the Olympic Final in ice hockey: Finland - Sweden!!!

How would having a builtin, "purist" boolean type preclude using integers as a boolean type, in all the old ways you describe? Just as a curiosity, how have you been burned in the past by "purist" thinking like this to make you so passionately against it?

I'd like to hear the answer :) . Have to stay at the purists side on this one. I like bool to be bool cause I'm that kind of guy that can't tolerate inconsistence (however I do tolerate it cause don't have much of a choice right now) and I'm putting all my hope in D. However both (the purist and the pragmatic) ways could coexist in the same language I guess. Tom;

I'm curious to know how you can tolerate the much impure int and real types while highly demanding a pure boolean. An integer bool is at least a superset of true booleans. Does that really bother people more?
Feb 26 2006
next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Mon, 27 Feb 2006 02:59:42 +1100, Wang Zhen <nehzgnaw gmail.com> wrote:


 I'm curious to know how you can tolerate the much impure int and real  
 types while highly demanding a pure boolean. An integer bool is at least  
 a superset of true booleans. Does that really bother people more?

'int' is not impure. It is a defined subset of integers. 'real' is not impure. It is a defined subset of reals. 'int' is not a superset of boolean. They are in different domains. You seem to be confusing implementation with theory. -- Derek Parnell Melbourne, Australia
Feb 26 2006
parent Kyle Furlong <kylefurlong gmail.com> writes:
Derek Parnell wrote:
 On Mon, 27 Feb 2006 02:59:42 +1100, Wang Zhen <nehzgnaw gmail.com> wrote:
 
 
 I'm curious to know how you can tolerate the much impure int and real 
 types while highly demanding a pure boolean. An integer bool is at 
 least a superset of true booleans. Does that really bother people more?

'int' is not impure. It is a defined subset of integers. 'real' is not impure. It is a defined subset of reals. 'int' is not a superset of boolean. They are in different domains. You seem to be confusing implementation with theory. --Derek Parnell Melbourne, Australia

This is what happens when the theorists collide with the hobbyists. ;(
Feb 26 2006
prev sibling next sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Wang Zhen wrote:
 I'm curious to know how you can tolerate the much impure int and real 
 types while highly demanding a pure boolean. An integer bool is at least 
 a superset of true booleans. Does that really bother people more?

A superset? Hmmm, integer bool has nothing to do with true booleans. And int and real would be impure why? Their behaviour is well defined and consistent.
Feb 26 2006
prev sibling parent reply Tom <Tom_member pathlink.com> writes:
In article <dtsj9u$1l2s$1 digitaldaemon.com>, Wang Zhen says...
Tom wrote:
 In article <dtsgbj$1h6u$3 digitaldaemon.com>, Kyle Furlong says...
 
Georg Wrede wrote:

Derek Parnell wrote:

Walter is still living in the C/C++ past with this concept, which is  
strange seeing he has implemented so many progressive concepts in D.  
Boolean as an integer is just retro.

So am I. Booleans have to be int. A boolean may have any "numeric" value, but if implicitly cast to a numeric type, it should return 1 or 0. D IS A PRACTICAL PROGRAMMING LANGUAGE. Forcing booleans to be 1/0 all the way is just academic, purist, impractical bigotry. About as smart as having the bit type. (Besides, if booleans, as some say here, are _only_ abstract concepts, then we might as well decide to have 0 mean true and 1 mean false. Heh, there's only one truth but millions of lies! But we live in a world with other people. And computers.) Now, specifying 0 to mean false and everything else to mean not-false, we go along with the hardware, the computer industry, half a century of programming PRACTICE, and make life less difficult for anybody with a professional programming background before moving to D. Anybody who wants a tight-ass boolean, can define one for themselves. //// Now off to the Olympic Final in ice hockey: Finland - Sweden!!!

How would having a builtin, "purist" boolean type preclude using integers as a boolean type, in all the old ways you describe? Just as a curiosity, how have you been burned in the past by "purist" thinking like this to make you so passionately against it?

I'd like to hear the answer :) . Have to stay at the purists side on this one. I like bool to be bool cause I'm that kind of guy that can't tolerate inconsistence (however I do tolerate it cause don't have much of a choice right now) and I'm putting all my hope in D. However both (the purist and the pragmatic) ways could coexist in the same language I guess. Tom;

I'm curious to know how you can tolerate the much impure int and real types while highly demanding a pure boolean. An integer bool is at least a superset of true booleans. Does that really bother people more?

I think people learns to tolerate things. It's just a matter of time. And now that you mention it, it doesn't bother me *that* much. Now it is more like a preference to me. Tom;
Feb 26 2006
parent Tom <Tom_member pathlink.com> writes:
In article <dttblu$2hr6$1 digitaldaemon.com>, Tom says...
In article <dtsj9u$1l2s$1 digitaldaemon.com>, Wang Zhen says...
Tom wrote:
 In article <dtsgbj$1h6u$3 digitaldaemon.com>, Kyle Furlong says...
 
Georg Wrede wrote:

Derek Parnell wrote:

Walter is still living in the C/C++ past with this concept, which is  
strange seeing he has implemented so many progressive concepts in D.  
Boolean as an integer is just retro.

So am I. Booleans have to be int. A boolean may have any "numeric" value, but if implicitly cast to a numeric type, it should return 1 or 0. D IS A PRACTICAL PROGRAMMING LANGUAGE. Forcing booleans to be 1/0 all the way is just academic, purist, impractical bigotry. About as smart as having the bit type. (Besides, if booleans, as some say here, are _only_ abstract concepts, then we might as well decide to have 0 mean true and 1 mean false. Heh, there's only one truth but millions of lies! But we live in a world with other people. And computers.) Now, specifying 0 to mean false and everything else to mean not-false, we go along with the hardware, the computer industry, half a century of programming PRACTICE, and make life less difficult for anybody with a professional programming background before moving to D. Anybody who wants a tight-ass boolean, can define one for themselves. //// Now off to the Olympic Final in ice hockey: Finland - Sweden!!!

How would having a builtin, "purist" boolean type preclude using integers as a boolean type, in all the old ways you describe? Just as a curiosity, how have you been burned in the past by "purist" thinking like this to make you so passionately against it?

I'd like to hear the answer :) . Have to stay at the purists side on this one. I like bool to be bool cause I'm that kind of guy that can't tolerate inconsistence (however I do tolerate it cause don't have much of a choice right now) and I'm putting all my hope in D. However both (the purist and the pragmatic) ways could coexist in the same language I guess. Tom;

I'm curious to know how you can tolerate the much impure int and real types while highly demanding a pure boolean. An integer bool is at least a superset of true booleans. Does that really bother people more?

I think people learns to tolerate things. It's just a matter of time. And now that you mention it, it doesn't bother me *that* much. Now it is more like a preference to me.

Sorry didn't understand before (part because of english not being my "home language" and part because of being distracted). Derek answered well to that. Now here is my thinking: if you don't like abstraction high level languages offer, please go back to C or even to assembly so you never forget you're dealing with transistors :P (just a joke) Tom;
Feb 26 2006
prev sibling parent reply Georg Wrede <georg nospam.org> writes:
Tom wrote:
 Kyle Furlong says...
 Georg Wrede wrote:
 Derek Parnell wrote:
 
 Walter is still living in the C/C++ past with this concept,
 which is strange seeing he has implemented so many progressive
 concepts in D. Boolean as an integer is just retro.

So am I. Booleans have to be int. A boolean may have any "numeric" value, but if implicitly cast to a numeric type, it should return 1 or 0. D IS A PRACTICAL PROGRAMMING LANGUAGE. Forcing booleans to be 1/0 all the way is just academic, purist, impractical bigotry. About as smart as having the bit type. (Besides, if booleans, as some say here, are _only_ abstract concepts, then we might as well decide to have 0 mean true and 1 mean false. Heh, there's only one truth but millions of lies! But we live in a world with other people. And computers.) Now, specifying 0 to mean false and everything else to mean not-false, we go along with the hardware, the computer industry, half a century of programming PRACTICE, and make life less difficult for anybody with a professional programming background before moving to D. Anybody who wants a tight-ass boolean, can define one for themselves. //// Now off to the Olympic Final in ice hockey: Finland - Sweden!!!

How would having a builtin, "purist" boolean type preclude using integers as a boolean type, in all the old ways you describe? Just as a curiosity, how have you been burned in the past by "purist" thinking like this to make you so passionately against it?

I'd like to hear the answer :) . Have to stay at the purists side on this one. I like bool to be bool cause I'm that kind of guy that can't tolerate inconsistence (however I do tolerate it cause don't have much of a choice right now) and I'm putting all my hope in D. However both (the purist and the pragmatic) ways could coexist in the same language I guess.

Well, then we could skip the logical operators, right? No more && or ||. Since all booleans would be strictly 0 or 1, they'd become obsolete. And if booleans have to only be 0 or 1, then a whole lot of unnecessary conversions would be happening all over the place. Forget D speed. Also, D is supposed to be a _systems_language_ for chrissake! Any kernel writing would then have to forgo booleans totally. I'm all for features in D that enhance productivity, but deliberately dumbing down the language is getting a bit too far. --- We've all had our fights with C, C++, and other related languages. But honestly, how many of us can confess to having problems with logical values? And if someone here has such problems, I suggest switching to VB. --- "Don't fix it if it ain't broke."
Feb 26 2006
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Georg Wrede wrote:
 Tom wrote:
 Kyle Furlong says...
 Georg Wrede wrote:
 Derek Parnell wrote:

 Walter is still living in the C/C++ past with this concept,
 which is strange seeing he has implemented so many progressive
 concepts in D. Boolean as an integer is just retro.

So am I. Booleans have to be int. A boolean may have any "numeric" value, but if implicitly cast to a numeric type, it should return 1 or 0. D IS A PRACTICAL PROGRAMMING LANGUAGE. Forcing booleans to be 1/0 all the way is just academic, purist, impractical bigotry. About as smart as having the bit type. (Besides, if booleans, as some say here, are _only_ abstract concepts, then we might as well decide to have 0 mean true and 1 mean false. Heh, there's only one truth but millions of lies! But we live in a world with other people. And computers.) Now, specifying 0 to mean false and everything else to mean not-false, we go along with the hardware, the computer industry, half a century of programming PRACTICE, and make life less difficult for anybody with a professional programming background before moving to D. Anybody who wants a tight-ass boolean, can define one for themselves. //// Now off to the Olympic Final in ice hockey: Finland - Sweden!!!

How would having a builtin, "purist" boolean type preclude using integers as a boolean type, in all the old ways you describe? Just as a curiosity, how have you been burned in the past by "purist" thinking like this to make you so passionately against it?

I'd like to hear the answer :) . Have to stay at the purists side on this one. I like bool to be bool cause I'm that kind of guy that can't tolerate inconsistence (however I do tolerate it cause don't have much of a choice right now) and I'm putting all my hope in D. However both (the purist and the pragmatic) ways could coexist in the same language I guess.

Well, then we could skip the logical operators, right? No more && or ||. Since all booleans would be strictly 0 or 1, they'd become obsolete. And if booleans have to only be 0 or 1, then a whole lot of unnecessary conversions would be happening all over the place. Forget D speed.

Why would this happen?
 
 Also, D is supposed to be a _systems_language_ for chrissake! Any kernel 
 writing would then have to forgo booleans totally.
 

I'm wracking my brain for any reason why this statement is even remotely true.
 I'm all for features in D that enhance productivity, but deliberately 
 dumbing down the language is getting a bit too far.
 

How is it dumbing down the language to instruct it in the correct contraints of the boolean type?
 ---
 
 We've all had our fights with C, C++, and other related languages. But 
 honestly, how many of us can confess to having problems with logical 
 values?
 
 And if someone here has such problems, I suggest switching to VB.
 
 ---
 
 "Don't fix it if it ain't broke."

Many would contend that it is, as you say, "broke."
Feb 26 2006
prev sibling next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Mon, 27 Feb 2006 06:05:13 +1100, Georg Wrede <georg nospam.org> wrote:


 Well, then we could skip the logical operators, right? No more && or ||.  
 Since all booleans would be strictly 0 or 1, they'd become obsolete.

Firstly, I'm not saying that booleans are 0 or 1 - they are not even numbers. Secondly, '&&' and '||' are logic operations and don't apply to numbers, they apply to booleans. if ((a < b) && (c >= b)) ... has meaning regardless of how booleans are implemented.
 And if booleans have to only be 0 or 1, then a whole lot of unnecessary  
 conversions would be happening all over the place. Forget D speed.

I repeat ... why are you saying the 0/1 is the only implementation being suggested? I'm not holding that position. Booleans can be implemented efficiently, and the compiler can implement boolean semantics, these are not mutually exclusive.
 Also, D is supposed to be a _systems_language_ for chrissake! Any kernel  
 writing would then have to forgo booleans totally.

Why? Your statement does not make any sense to me.
 I'm all for features in D that enhance productivity, but deliberately  
 dumbing down the language is getting a bit too far.

You mean that by making D smarter about the use of booleans would actually make it dumber?
 We've all had our fights with C, C++, and other related languages. But  
 honestly, how many of us can confess to having problems with logical  
 values?

Me.
 And if someone here has such problems, I suggest switching to VB.

I am also a VB coder and I'm not a language bigot.
 "Don't fix it if it ain't broke."

D is broken with respect to booleans. A little less broken than before, but still broken. -- Derek Parnell Melbourne, Australia
Feb 26 2006
parent reply Georg Wrede <georg nospam.org> writes:
Derek Parnell wrote:
 On Mon, 27 Feb 2006 06:05:13 +1100, Georg Wrede <georg nospam.org> wrote:

 We've all had our fights with C, C++, and other related languages. 
 But  honestly, how many of us can confess to having problems with 
 logical  values?

Me.
 And if someone here has such problems, I suggest switching to VB.

I am also a VB coder and I'm not a language bigot.

Oh. I'm sorry. I'll try not to mention VB in the future. --- I think we've gotten it backwards here, so let's turn the table: Can you give some example code and use cases where we absolutely need your kind of booleans?
Feb 26 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Georg Wrede wrote:
 Derek Parnell wrote:
 
 On Mon, 27 Feb 2006 06:05:13 +1100, Georg Wrede <georg nospam.org> wrote:

 We've all had our fights with C, C++, and other related languages. 
 But  honestly, how many of us can confess to having problems with 
 logical  values?

Me.
 And if someone here has such problems, I suggest switching to VB.

I am also a VB coder and I'm not a language bigot.

Oh. I'm sorry. I'll try not to mention VB in the future. --- I think we've gotten it backwards here, so let's turn the table: Can you give some example code and use cases where we absolutely need your kind of booleans?

Ok, I'll give an example of that right after you give an example of why and where this is needed/good/(not extremly bad): bool a, b, c; a = true; b = true; c = true; a = b+c; // true + true is what? if(5) //if 5 what? what does that mean (except nothing)? { writefln("5"); }
Feb 26 2006
parent reply Georg Wrede <georg nospam.org> writes:
Ivan Senji wrote:
 Georg Wrede wrote:
 
 Derek Parnell wrote:

 On Mon, 27 Feb 2006 06:05:13 +1100, Georg Wrede <georg nospam.org> 
 wrote:

 We've all had our fights with C, C++, and other related languages. 
 But  honestly, how many of us can confess to having problems with 
 logical  values?

Me.
 And if someone here has such problems, I suggest switching to VB.

I am also a VB coder and I'm not a language bigot.

Oh. I'm sorry. I'll try not to mention VB in the future. --- I think we've gotten it backwards here, so let's turn the table: Can you give some example code and use cases where we absolutely need your kind of booleans?

Ok, I'll give an example of that right after you give an example of why and where this is needed/good/(not extremly bad): bool a, b, c; a = true; b = true; c = true; a = b+c; // true + true is what?

That's why we do want to have booleans. The whole point of having booleans is to not do that by mistake.
   if(5) //if 5 what? what does that mean (except nothing)?

Ever seen this: while(1) written in source code? Or this: c = getCharacter(inf); if (c) { /* whatever */ } Oh, by the way, just checked how many times 'while(1)' appears in src/phobos/std: grep "while *( *1 *)" *.d |wc answer: 16 times. --- Now, let's see your promised example.
Feb 26 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Georg Wrede wrote:
 Ivan Senji wrote:
 
 Georg Wrede wrote:

 Derek Parnell wrote:

 On Mon, 27 Feb 2006 06:05:13 +1100, Georg Wrede <georg nospam.org> 
 wrote:

 We've all had our fights with C, C++, and other related languages. 
 But  honestly, how many of us can confess to having problems with 
 logical  values?

Me.
 And if someone here has such problems, I suggest switching to VB.

I am also a VB coder and I'm not a language bigot.

Oh. I'm sorry. I'll try not to mention VB in the future. --- I think we've gotten it backwards here, so let's turn the table: Can you give some example code and use cases where we absolutely need your kind of booleans?



Could it be that I missunderstood you? By your kind of booleans did you mean the true non-integer booleans? If so, that is what the example dow there is for: showing why we need real bools. And if I did missunderstand something I apologize (it's late).
 Ok, I'll give an example of that right after you give an example of 
 why and where this is needed/good/(not extremly bad):

   bool a, b, c;
   a = true;
   b = true;
   c = true;

   a = b+c; // true + true is what?

That's why we do want to have booleans. The whole point of having booleans is to not do that by mistake.

Are you now saying you want real booleans that are not ints?
 
   if(5) //if 5 what? what does that mean (except nothing)?

Ever seen this: while(1)

I sure did, and it scares the hell out of me :)
 
 written in source code?
 
 Or this:
 
 c = getCharacter(inf);
 if (c) { /* whatever */ }

...even worse :)
 
 
 Oh, by the way, just checked how many times 'while(1)' appears in 
 src/phobos/std:
 
 grep "while *( *1 *)" *.d |wc
 
 answer: 16 times.
 

Scary.
 ---
 
 Now, let's see your promised example.

My example was supposed to be an example for: a) real bools being needed b) int bool being bad
Feb 26 2006
next sibling parent reply Georg Wrede <georg nospam.org> writes:
Ivan Senji wrote:
 Georg Wrede wrote:
 
 Ivan Senji wrote:

 Georg Wrede wrote:

 Derek Parnell wrote:

 On Mon, 27 Feb 2006 06:05:13 +1100, Georg Wrede <georg nospam.org> 
 wrote:

 We've all had our fights with C, C++, and other related languages. 
 But  honestly, how many of us can confess to having problems with 
 logical  values?

Me.
 And if someone here has such problems, I suggest switching to VB.

I am also a VB coder and I'm not a language bigot.

Oh. I'm sorry. I'll try not to mention VB in the future. --- I think we've gotten it backwards here, so let's turn the table: Can you give some example code and use cases where we absolutely need your kind of booleans?



Could it be that I missunderstood you? By your kind of booleans did you mean the true non-integer booleans? If so, that is what the example dow there is for: showing why we need real bools. And if I did missunderstand something I apologize (it's late).

No problem. The way this whole thread is going, half the time everybody is clueless. :-)
 Ok, I'll give an example of that right after you give an example of 
 why and where this is needed/good/(not extremly bad):

   bool a, b, c;
   a = true;
   b = true;
   c = true;

   a = b+c; // true + true is what?

That's why we do want to have booleans. The whole point of having booleans is to not do that by mistake.

Are you now saying you want real booleans that are not ints?

On the inside they should be ints. Mostly for efficiency reasons, but also for established coding conventions. But on the outside, they should not be compatible with ints. In other words, doing bool foo = 55 && 5000; should be legal, and it should store the 'true value' (that'd be a 1) into foo. But doing: bool a = 1; // legal, but poor coding bool b = 0; // likewise whateverType bar = a + b; // should produce a compiler error // since addition of bools is illegal
   if(5) //if 5 what? what does that mean (except nothing)?

Ever seen this: while(1)

I sure did, and it scares the hell out of me :)
 written in source code?

 Or this:

 c = getCharacter(inf);
 if (c) { /* whatever */ }

...even worse :)
 Oh, by the way, just checked how many times 'while(1)' appears in 
 src/phobos/std:

 grep "while *( *1 *)" *.d |wc

 answer: 16 times.

Scary.

 Now, let's see your promised example.

My example was supposed to be an example for: a) real bools being needed b) int bool being bad

I'm still waiting.
Feb 26 2006
next sibling parent reply Tom <Tom_member pathlink.com> writes:
In article <44024375.4060101 nospam.org>, Georg Wrede says...
Ivan Senji wrote:
 Georg Wrede wrote:
 
 Ivan Senji wrote:

 Georg Wrede wrote:

 Derek Parnell wrote:

 On Mon, 27 Feb 2006 06:05:13 +1100, Georg Wrede <georg nospam.org> 
 wrote:

 We've all had our fights with C, C++, and other related languages. 
 But  honestly, how many of us can confess to having problems with 
 logical  values?

Me.
 And if someone here has such problems, I suggest switching to VB.

I am also a VB coder and I'm not a language bigot.

Oh. I'm sorry. I'll try not to mention VB in the future. --- I think we've gotten it backwards here, so let's turn the table: Can you give some example code and use cases where we absolutely need your kind of booleans?



Could it be that I missunderstood you? By your kind of booleans did you mean the true non-integer booleans? If so, that is what the example dow there is for: showing why we need real bools. And if I did missunderstand something I apologize (it's late).

No problem. The way this whole thread is going, half the time everybody is clueless. :-)
 Ok, I'll give an example of that right after you give an example of 
 why and where this is needed/good/(not extremly bad):

   bool a, b, c;
   a = true;
   b = true;
   c = true;

   a = b+c; // true + true is what?

That's why we do want to have booleans. The whole point of having booleans is to not do that by mistake.

Are you now saying you want real booleans that are not ints?

On the inside they should be ints. Mostly for efficiency reasons, but also for established coding conventions. But on the outside, they should not be compatible with ints. In other words, doing bool foo = 55 && 5000;

Oh my God!
should be legal, and it should store the 'true value' (that'd be a 1) 
into foo.

But doing:

bool a = 1;  // legal, but poor coding
bool b = 0;  // likewise
whateverType bar = a + b;  // should produce a compiler error
                            // since addition of bools is illegal

   if(5) //if 5 what? what does that mean (except nothing)?

Ever seen this: while(1)

I sure did, and it scares the hell out of me :)
 written in source code?

 Or this:

 c = getCharacter(inf);
 if (c) { /* whatever */ }

...even worse :)
 Oh, by the way, just checked how many times 'while(1)' appears in 
 src/phobos/std:

 grep "while *( *1 *)" *.d |wc

 answer: 16 times.

Scary.

 Now, let's see your promised example.

My example was supposed to be an example for: a) real bools being needed b) int bool being bad

I'm still waiting.

Really I can't see yet why you don't like the pure bool. We should see an example of why pure bools would bother you so much. Tom;
Feb 26 2006
parent reply Georg Wrede <georg nospam.org> writes:
Tom wrote:
 Georg Wrede says...
 Ivan Senji wrote:
 Georg Wrede wrote:
 Ivan Senji wrote:
 Georg Wrede wrote:
 Derek Parnell wrote:
 Georg Wrede wrote:







 I think we've gotten it backwards here, so let's turn the table:

 Can you give some example code and use cases where we absolutely 
 need your kind of booleans?



Could it be that I missunderstood you? By your kind of booleans did you mean the true non-integer booleans? If so, that is what the example dow there is for: showing why we need real bools. And if I did missunderstand something I apologize (it's late).

No problem. The way this whole thread is going, half the time everybody is clueless. :-)


 bool foo = 55 && 5000;

Oh my God!

 Really I can't see yet why you don't like the pure bool. We should see an
 example of why pure bools would bother you so much.

In this post alone, there's a half dozen references to "my kind of bool" or "your kind of bool", by various people. Probably somebody should start making a table of their properties! :-) And if they don't, we could always examine this thread later, and I bet we could find one or two pairs of folks vehemently arguing, and it'd turn out "their bools were the same", only they didn't notice.
Feb 26 2006
next sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Georg Wrede wrote:
 Tom wrote:
 
 Georg Wrede says...

 Ivan Senji wrote:

 Georg Wrede wrote:

 Ivan Senji wrote:

 Georg Wrede wrote:

 Derek Parnell wrote:

 Georg Wrede wrote:








This above looks cool.
 
 I think we've gotten it backwards here, so let's turn the table:

 Can you give some example code and use cases where we absolutely 
 need your kind of booleans?



Could it be that I missunderstood you? By your kind of booleans did you mean the true non-integer booleans? If so, that is what the example dow there is for: showing why we need real bools. And if I did missunderstand something I apologize (it's late).

No problem. The way this whole thread is going, half the time everybody is clueless. :-)


 bool foo = 55 && 5000;

Oh my God!

 Really I can't see yet why you don't like the pure bool. We should see an
 example of why pure bools would bother you so much.

In this post alone, there's a half dozen references to "my kind of bool" or "your kind of bool", by various people.

Funny thread.
 
 Probably somebody should start making a table of their properties! :-)
 
 And if they don't, we could always examine this thread later, and I bet 
 we could find one or two pairs of folks vehemently arguing, and it'd 
 turn out "their bools were the same", only they didn't notice.

After all, what ever bizare variant of a bool gets implemented, it is still out D's bool :)
Feb 26 2006
prev sibling parent Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Georg Wrede skrev:
 Tom wrote:
 Georg Wrede says...
 Ivan Senji wrote:
 Georg Wrede wrote:
 Ivan Senji wrote:
 Georg Wrede wrote:
 Derek Parnell wrote:
 Georg Wrede wrote:








[snip]
 In this post alone, there's a half dozen references to "my kind of bool" 
 or "your kind of bool", by various people.
 
 Probably somebody should start making a table of their properties! :-)

Lets try. First the two extremes: Numerical bool ------------- True is 1, false is 0. Math is computed in a modulo-2 algebra (the result of all operations is computed mod (%) 2). This bool is an integer type, and should also be implicitly castable to int. Analogous to the unsigned integer types: bool: mod 2 algebra ubyte: mod 256 algebra ushort: mod 65536 algebra uint: mod 4294967296 algebra ulong: mod 18446744073709551616 algebra Boolean operators (&,|,^,~,...) works as expected and are implementable efficiently. Arithmetic operators have the following properties: + behaves like xor (1+1 = 0) * behaves like and This type can be implemented efficiently as an (1, 2, 4, ...)-byte integer by either a) always mask the result of any operation cast to a bool by by &1 or b) consider all bits but the least significant to be undefined (meaning mask &1 when cast to a longer type) Downside: Even integers (2,4,...) would be cast into a boolean 0 (false). This is the pure numeric bool type. CPU-friendly. Logical bool ------------ True and false are the only allowed values of this boolean variable. The internal representation is irrelevant. Boolean operators behaves as expected. Arithmetic operators should either be: a) forbidden, or b) defined as in boolean algebra (* == and, + == or, ~ == not). This bool should not be implicitly convertible to anything and should not be allowed to take place in arithmetics with other types. Is this less CPU-friendly than a numerical bool? See comments below. C++ bool, C99 _Bool ------------------- C++ and C99 defines its boolean somewhere in between the Numerical and the Logical boolean (i.e. gets none of them right). The bool type is defined to be a numeric type implicitly castable to int (and therefore promotes to int/uint). Casting anything (x) to a bool yields 1 unless x == 0. This makes this bool-type quite different from a pure numeric type: (Consider x a boolean variable.) There are no overflows: ++x, x++, x += 1 all sets x to 1. But there are underflows: --x, x--, x -= 1 flips the value of x. Even though much caution is taken making sure a bool only ever has the value 1 or 0, the integer promotion breaks everything: bool a = true; bool b = a+a; assert(b == true); // OK assert(a+a == true); // FAILS assert(a+true == true); // FAILS assert(true+true == true); // FAILS Hence the rule: Never compare anything to true. (Or never use arithmetic operations on a bool.) Java boolean ------------ The Java boolean follows the definition of Logical bool above, and disables arithmetic operators. Bools are never promoted to ints. Bools can not even be cast to ints. There are no caveats using the Java boolean type, but you occasionally need to write a bit more code to make the compiler happy. D bool ------ I'm not fully aware how bools now are defined in D. The basic idea seems to be the same as C99/C++, but with one small difference: - Can not implicitly convert integer literals other than 0 and 1 to bool. This difference feels slightly inconsistent because you can implicitly convert a non literal integer to a bool. (There is also another difference that is likely a bug (*) ) Can anyone please fill in what other differences there are? Comments -------- Integer promotion makes "== true" a trap just waiting to be sprung for a numerical bool. The advantages of being able to do arithmetics on a bool are cases such as: bool addPadding = something(); int pos = 10 + addPadding * 5; Compared to: int pos = 10 + addPadding ? 5 : 0; Could help a compiler avoid a branching instruction... But you get the branching when forcing the bool to {0,1} instead. Are there any other advantages? Could a logical bool not be defined as being true when !0 and false otherwise, without the need to clamp it to {0,1}? Would this not be more efficient than the current bool? This would mean that the argument against opEquals returning a bool would vanish for instance. The only thing that would be less efficient would be comparing two boolean variables with each other (a rare occurrence) and that would not be less efficient than today unless there are many more comparisons than assignments. With dead horses in mind, my suggestion would be to make the D bool a _logical_ bool that is implicitly convertible _from_ any type that can be used as a condition expression (if(...)) but not _to_ any other type. Internal representation is irrelevant (could even be an ABI-thing). /Oskar --- *) The other difference in D bool that is likely a bug: - Like C99/C++, D makes sure that anything (x) cast to a bool yields 1 unless x == 0, but differs when arithmetics are done on the bool type itself: bool a = 0; --a; assert(a == false || a == true); // FAILS(!) (a is set to 255) bool t = true; bool b = t+t; assert(b == true); //OK bool c = 0; c++; c++; assert(c == true || c == false); // FAILS But: bool d = 0; d += 2; assert(d == true || d == false); // OK The last case works due to promotion bool -> int -> bool but the failing cases do not take that route. (being consistent, the definitions of post/predec of a bool should be to flip its value and post/preinc should set it to true)
Feb 27 2006
prev sibling next sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Georg Wrede wrote:
 Ivan Senji wrote:
 And if I did missunderstand something I apologize (it's late).

No problem. The way this whole thread is going, half the time everybody is clueless. :-)

:)
 Are you now saying you want real booleans that are not ints?

On the inside they should be ints. Mostly for efficiency reasons, but also for established coding conventions.

I agree completly that on the inside they should be ints for some reasons. But not as a must. On a different arhitecture something else might be more efficient.
 
 But on the outside, they should not be compatible with ints.
 
 In other words, doing
 
 bool foo = 55 && 5000;
 
 should be legal, 

You trying to scare me away from this thread? ;) I believe programming language constructs should(mostly) be translatable to a human language. but: if(55){Georg.giveApple();} means: if 55 give Georg an apple. Does Georg expect to get an apple? I really don't know. This doesn't have any meaning.
 and it should store the 'true value' (that'd be a 1) 
 into foo.

If by "store the 'true value' into foo" you mean "compile time error: cannot implicitly conver from int to bool" than I agree! :)
 
 But doing:
 
 bool a = 1;  // legal, but poor coding
 bool b = 0;  // likewise
 whateverType bar = a + b;  // should produce a compiler error
                            // since addition of bools is illegal

Hm! Addition of bools is illegal but assigning random integers into them is OK.
 My example was supposed to be an example for:
 a) real bools being needed
 b) int bool being bad

I'm still waiting.

No need to wait, the examples are there. :)
Feb 26 2006
prev sibling parent Tom <Tom_member pathlink.com> writes:
[snip]

This really looks like a chat by now. We should get into an IRC (despite I don't
personally like chatting over IRC kind of chats). :P


Tom;
Feb 26 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
news:dttebh$2kqq$1 digitaldaemon.com...
 Ever seen this:

 while(1)

I sure did, and it scares the hell out of me :)

Why? This is a practice I got into with C/C++, and I did it because 1 cannot be redefined by the preprocessor into something goofy. I.e., I *knew* what it was without having to go spelunking through header files.
Feb 26 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:
 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
 news:dttebh$2kqq$1 digitaldaemon.com...
 
Ever seen this:

while(1)

I sure did, and it scares the hell out of me :)

Why? This is a practice I got into with C/C++, and I did it because 1 cannot be redefined by the preprocessor into something goofy. I.e., I *knew* what it was without having to go spelunking through header files.

The reason should be obvious. While(condition). Condition should be boolean (true or false). 1 is neither. It is an integer. Using 1 (or any other int) in a conditions place just isn't type safe. What if you (as a compiler writer) decide (how ever unlikely) that true should for some good reasons be implemented as being 0, or bool should be implemented as float, or something else). PS No need to answer because I know this is one topic where we can't convince you. :)
Feb 26 2006
next sibling parent Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <dtuatr$l0k$1 digitaldaemon.com>, Ivan Senji says...
Walter Bright wrote:
 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
 news:dttebh$2kqq$1 digitaldaemon.com...
 
Ever seen this:

while(1)

I sure did, and it scares the hell out of me :)

Why? This is a practice I got into with C/C++, and I did it because 1 cannot be redefined by the preprocessor into something goofy. I.e., I *knew* what it was without having to go spelunking through header files.

The reason should be obvious. While(condition). Condition should be boolean (true or false). 1 is neither. It is an integer. Using 1 (or any other int) in a conditions place just isn't type safe.

One of my students once had code written like this: bool b1 = ... complex expression ... ; .. bool b2 = ... complex expression ... ; .. bool b3 = ... complex expression ... ; .. if (b1 || (b2 && 3)) { .. remove the file ... } (note the 'b' missing from 'b3'). Its program obviously removed the file at every run, no matter how it set the three variables, even when the debugger said they were false all the three. When I explained the student that 3 is always true, he asked to me: "Why? What '3' has in common with 'true'?". I didn't know what to say. Then the students complained at me that the compiler was buggy, since it didn't signal that construct as an error. It took me one hour to explain this C/C++ design flaw/decision, but I think I didn't convince them all. Ciao
Feb 27 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
news:dtuatr$l0k$1 digitaldaemon.com...
 Walter Bright wrote:
 Why? This is a practice I got into with C/C++, and I did it because 1 
 cannot be redefined by the preprocessor into something goofy. I.e., I 
 *knew* what it was without having to go spelunking through header files.

boolean (true or false). 1 is neither. It is an integer. Using 1 (or any other int) in a conditions place just isn't type safe.

1 isn't type safe??
 What if you (as a compiler writer) decide (how ever unlikely) that true 
 should for some good reasons be implemented as being 0, or bool should be 
 implemented as float, or something else).

That would break just about every C and C++ program in existence. Not going to happen. The reason I used 1 was because *it could never break* and because it has the property of being "inspectible." Inspectible means I can look at it and know what it does without having to refer to other things.
 PS No need to answer because I know this is one topic where we can't 
 convince you. :)

LOL, I agree with you there.
Feb 27 2006
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 27 Feb 2006 13:49:14 -0800, Walter Bright wrote:

 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
 news:dtuatr$l0k$1 digitaldaemon.com...
 Walter Bright wrote:
 Why? This is a practice I got into with C/C++, and I did it because 1 
 cannot be redefined by the preprocessor into something goofy. I.e., I 
 *knew* what it was without having to go spelunking through header files.

boolean (true or false). 1 is neither. It is an integer. Using 1 (or any other int) in a conditions place just isn't type safe.

1 isn't type safe??
 What if you (as a compiler writer) decide (how ever unlikely) that true 
 should for some good reasons be implemented as being 0, or bool should be 
 implemented as float, or something else).

That would break just about every C and C++ program in existence. Not going to happen. The reason I used 1 was because *it could never break* and because it has the property of being "inspectible." Inspectible means I can look at it and know what it does without having to refer to other things.
 PS No need to answer because I know this is one topic where we can't 
 convince you. :)

LOL, I agree with you there.

Agreed that the 'while(1)' idiom is not going anywhere, but Walter, which would *you* write using D nowadays? while(1) ... or while(true) ... And why would you choose one form over the other? -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 28/02/2006 9:41:18 AM
Feb 27 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:14g4upyin8106$.uuzir980l0jb.dlg 40tude.net...
 Agreed that the 'while(1)' idiom is not going anywhere, but Walter, which
 would *you* write using D nowadays?

  while(1) ...

 or

  while(true) ...

 And why would you choose one form over the other?

They are both equivalent. There is no technical, usability, portability, efficiency, or aesthetic advantage to one form over the other. I'd likely use the former simply out of habit and because it is shorter. As far as I'm concerned, arguing about it is like arguing over if the { goes on the same line or the next :-) What I especially think is bad style, however, are things like: const int forever = 1; ... while (forever) ... I don't see them too often, but it does happen.
Feb 28 2006
next sibling parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Walter Bright wrote:
 "Derek Parnell" <derek psych.ward> wrote in message 
 news:14g4upyin8106$.uuzir980l0jb.dlg 40tude.net...
 Agreed that the 'while(1)' idiom is not going anywhere, but Walter, which
 would *you* write using D nowadays?

  while(1) ...

 or

  while(true) ...

 And why would you choose one form over the other?

They are both equivalent. There is no technical, usability, portability, efficiency, or aesthetic advantage to one form over the other. I'd likely use the former simply out of habit and because it is shorter. As far as I'm

As for the usability/aesthetic advantage, it's arguable that there's no difference. I prefer the 'true' version, as I find it more expressive, even if the difference is not that big and while(1) doesn't bother me that much.
 concerned, arguing about it is like arguing over if the { goes on the same 
 line or the next :-)
 

could be said about it. :D -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Feb 28 2006
prev sibling next sibling parent reply Tom <Tom_member pathlink.com> writes:
In article <du187e$14bk$4 digitaldaemon.com>, Walter Bright says...
"Derek Parnell" <derek psych.ward> wrote in message 
 [snip]


As far as I'm 
concerned, arguing about it is like arguing over if the { goes on the same 
line or the next :-)

No no no, excuse me, nobody argues that because everybody knows that '{' and '}' goes in the next line, NEVER IN THE SAME!! :P Sorry, I couldn't resist! :D Tom;
Feb 28 2006
parent James Dunne <james.jdunne gmail.com> writes:
Tom wrote:
 In article <du187e$14bk$4 digitaldaemon.com>, Walter Bright says...
 
"Derek Parnell" <derek psych.ward> wrote in message 

[snip]


As far as I'm 
concerned, arguing about it is like arguing over if the { goes on the same 
line or the next :-)

No no no, excuse me, nobody argues that because everybody knows that '{' and '}' goes in the next line, NEVER IN THE SAME!! :P Sorry, I couldn't resist! :D Tom;

Gosh I couldn't stand looking at all those wasted lines. C# default style is the worst, luckily I can change it in VS.Net 2003. My vertical screen space is limited; I'd prefer getting as big a picture as I can get on the screen at once, especially seeing as how my sight is surely going and my fonts are getting bigger. And spaces for indentation? Oh please, this is what we have tab characters for. And why the hell do they want to stay at 8 characters wide? Sure this works for C code, but now we've got many more coding practices and constructs for langauges that *require* more nesting of branches, hence more tabs, and hence a more horizontal exspanse of code. Nothing is wrong with your code and you simply shouldn't have to break things up into functions. 2 is too small, 8 is too big -- 4 is just right :) 3? Who invited you? =P -- Regards, James Dunne
Feb 28 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 
 What I especially think is bad style, however, are things like:
 
     const int forever = 1;
     ...
     while (forever) ...
 
 I don't see them too often, but it does happen. 

It perhaps sidesteps the issue, but I use "for(;;)" in these cases, mostly because it avoids a constant conditional warning in VC++ :-p "while(true)" is probably a bit more meaningful however as it's not a counting loop. Sean
Feb 28 2006
next sibling parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Sean Kelly wrote:
 It perhaps sidesteps the issue, but I use "for(;;)" in these cases,
 mostly because it avoids a constant conditional warning in VC++ :-p
 "while(true)" is probably a bit more meaningful however as it's not a
 counting loop.

I use that as well. It even defeats the "while (1) is shorter" argument by being one character shorter. <g>
Feb 28 2006
prev sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Wed, 01 Mar 2006 04:23:00 +1100, Sean Kelly <sean f4.ca> wrote:

 Walter Bright wrote:
  What I especially think is bad style, however, are things like:
      const int forever = 1;
     ...
     while (forever) ...
  I don't see them too often, but it does happen.

It perhaps sidesteps the issue, but I use "for(;;)" in these cases, mostly because it avoids a constant conditional warning in VC++ :-p "while(true)" is probably a bit more meaningful however as it's not a counting loop.

And I remember somebody writing .. #define forever for(;;) . . . forever{ . . . } -- Derek Parnell Melbourne, Australia
Feb 28 2006
next sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Derek Parnell wrote:

 And I remember somebody writing ..
 
   #define forever for(;;)
 
   . . .
 
   forever{
       . . .
      }

I'm pretty sure that I saw a : #define EVER ;; As in: for (EVER) { young() } --anders
Feb 28 2006
parent Sean Kelly <sean f4.ca> writes:
Anders F Björklund wrote:
 Derek Parnell wrote:
 
 And I remember somebody writing ..

   #define forever for(;;)

   . . .

   forever{
       . . .
      }

I'm pretty sure that I saw a : #define EVER ;; As in: for (EVER) { young() }

LOL Sean
Feb 28 2006
prev sibling next sibling parent James Dunne <james.jdunne gmail.com> writes:
Derek Parnell wrote:
 On Wed, 01 Mar 2006 04:23:00 +1100, Sean Kelly <sean f4.ca> wrote:
 
 Walter Bright wrote:

  What I especially think is bad style, however, are things like:
      const int forever = 1;
     ...
     while (forever) ...
  I don't see them too often, but it does happen.

It perhaps sidesteps the issue, but I use "for(;;)" in these cases, mostly because it avoids a constant conditional warning in VC++ :-p "while(true)" is probably a bit more meaningful however as it's not a counting loop.

And I remember somebody writing .. #define forever for(;;) . . . forever{ . . . }

It's called "Better C" http://thedailywtf.com/forums/60255/ShowPost.aspx /* * BETTER_C.H * Language refinements for C. */ #ifndef BETTER_C_H #define BETTER_C_H /* logical/comparison operators */ #define NE != #define EQ == #define GT > #define LT < #define GE >= #define LE <= #define AND && #define OR || #define NOT ! /* bitwise operators */ #define bNOT ~ #define bAND & #define bOR | #define bXOR ^ /* arithmetic operators */ #define MOD % /* control constructs */ #define repeat do #define until(p) while(NOT (p)) #define forever while(1) #define untilbreak forever #define untilreturn forever #define unless(p) if(NOT (p)) #define ifnot(p) if(NOT (p)) #define do_nothing #define then ... #endif -- Regards, James Dunne
Feb 28 2006
prev sibling parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Derek Parnell wrote:
 And I remember somebody writing ..
 
   #define forever for(;;)
 
   . . .
 
   forever{
       . . .
      }
 

Hey, I still think it's fun to do like I did in my early C coding days (a few years back) and #define EVER (;;) and then loop for EVER { }
Mar 01 2006
prev sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:
 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
 news:dtuatr$l0k$1 digitaldaemon.com...
 
Walter Bright wrote:


I told you not to reply :) ...
Why? This is a practice I got into with C/C++, and I did it because 1 
cannot be redefined by the preprocessor into something goofy. I.e., I 
*knew* what it was without having to go spelunking through header files.

The reason should be obvious. While(condition). Condition should be boolean (true or false). 1 is neither. It is an integer. Using 1 (or any other int) in a conditions place just isn't type safe.

1 isn't type safe??

LOL, 1 is a perfectly safe integer, but not a safe boolean. The code could have been while(5). Do you really think 5 is true?
 
 
What if you (as a compiler writer) decide (how ever unlikely) that true 
should for some good reasons be implemented as being 0, or bool should be 
implemented as float, or something else).

That would break just about every C and C++ program in existence. Not going to happen. The reason I used 1 was because *it could never break* and because it has the property of being "inspectible." Inspectible means I can look at it and know what it does without having to refer to other things.

I know it isn't going to happen. To point was: this is exposing implementation to everyone, and that is generally regarded as not a good thing to do. The problem in all these bool wars so far is I never saw an argument that would be against true booleans (while(BooleanExpression) and all that...). The arguments like: while(true) is much much bigger than while(1) or while(a) is much smaller and more understandable than while(a>0) //hm while(a) is actually while(a!=0) but did I really mean a>0?) and like that don't really count. Adding true booleans makes no code break, only adds compiler errors that make a coder think more about what he is doing and require awfull changes from if(b) to if(b!=0) and stop him from doing things like adding two bools or adding an int to a bool.
 
PS No need to answer because I know this is one topic where we can't 
convince you. :)

LOL, I agree with you there.

I still wonder why do you think that many modern and much used languages implement real boolean types and are very proud of that? Does the behaviour of D really fix C/C++ bool isues? Will those seeking a real bool people not say <g> and write alias/typedef int boolean, or something else? I think those languages have bools because they realize bool is *not* an int but a mathematical concept.
Feb 27 2006
next sibling parent reply Tom <Tom_member pathlink.com> writes:
In article <du002m$2pnp$1 digitaldaemon.com>, Ivan Senji says...
Walter Bright wrote:
 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
Walter Bright wrote:



The problem in all these bool wars so far is I never saw an argument 
that would be against true booleans (while(BooleanExpression) and all 
that...).

Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I shut my mouth forever! Tom;
Feb 27 2006
next sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Tom wrote:
 In article <du002m$2pnp$1 digitaldaemon.com>, Ivan Senji says...
The problem in all these bool wars so far is I never saw an argument 
that would be against true booleans (while(BooleanExpression) and all 
that...).

Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I shut my mouth forever!

LOL, So true :)
Feb 27 2006
prev sibling next sibling parent Lucas Goss <lgoss007 gmail.com> writes:
Tom wrote:
 In article <du002m$2pnp$1 digitaldaemon.com>, Ivan Senji says...
 Walter Bright wrote:
 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
 Walter Bright wrote:



 The problem in all these bool wars so far is I never saw an argument 
 that would be against true booleans (while(BooleanExpression) and all 
 that...).

Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I shut my mouth forever! Tom;

I don't understand this either. Just because I did things in C/C++ (I have used while(1) quite a few times before) I don't see how this affects D. It may be a surprise coming from C/C++, but it can't be that hard to change while(1), to while(true). The only argument I can see against it is existing D code that uses while(1). But then why should progress be inhibited by past mistakes... well I guess it's common for system languages, just look at the stuff C/C++ has trouble fixing... :) I'd even be willing to convert everyones D code for them... um, I hope there aren't too many D programmers out there :)
Feb 27 2006
prev sibling next sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Tom skrev:
 In article <du002m$2pnp$1 digitaldaemon.com>, Ivan Senji says...
 Walter Bright wrote:
 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
 Walter Bright wrote:



 The problem in all these bool wars so far is I never saw an argument 
 that would be against true booleans (while(BooleanExpression) and all 
 that...).

Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I shut my mouth forever! Tom;

Does pure booleans necessarily mean that other types could not be implicitly convertible to bool? I would love "pure" booleans (not a numeric type, not allowed in arithmetic operations), but I would hate to have to write: if (a !is null || b !is null) instead of: if (a || b) What is wrong with the second case? (apart from being more readable). With such "pure" booleans, you could still write: while(1) With the classic definition of !0 !null implies true... /Oskar
Feb 28 2006
next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Oskar Linde wrote:
 Tom skrev:
 In article <du002m$2pnp$1 digitaldaemon.com>, Ivan Senji says...
 Walter Bright wrote:
 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
 Walter Bright wrote:



 The problem in all these bool wars so far is I never saw an argument 
 that would be against true booleans (while(BooleanExpression) and all 
 that...).

Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I shut my mouth forever! Tom;

Does pure booleans necessarily mean that other types could not be implicitly convertible to bool? I would love "pure" booleans (not a numeric type, not allowed in arithmetic operations), but I would hate to have to write: if (a !is null || b !is null) instead of: if (a || b)

I would say that the second construct is much less reliable, maintainable, and safe than the first. Therefore, the type system should disallow the second with a pure boolean type.
 What is wrong with the second case? (apart from being more readable).
 
 With such "pure" booleans, you could still write:
 
 while(1)
 
 With the classic definition of !0 !null implies true...
 
 /Oskar

Feb 28 2006
next sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Kyle Furlong skrev:
 Oskar Linde wrote:
 if (a !is null || b !is null)

 instead of:

 if (a || b)

I would say that the second construct is much less reliable, maintainable, and safe than the first. Therefore, the type system should disallow the second with a pure boolean type.

I have seen bugs introduced by changing if(!a || !b) into if(a !is null || b !is null) And the double negation nature of !is null makes this quite hard to spot (for both me and the one introducing the bug). This contradicts your saying that it makes the code "much more reliable, maintainable and safe". Consider the sentences: "If a or b" compared to: "If a is not nothing or b is not nothing" Which one is easier to grasp and get right? (!is also takes an extra step when it is parsed by the reader as "not is" and then (in most western languages at least) has to be transformed into "is not") What do you base your statements on? Do you have examples of where (a||b) is less reliable or less safe? Why would it be less maintainable? It is clearer (less complex) an has a well defined semantic meaning. JMHO /Oskar
Feb 28 2006
parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Oskar Linde wrote:
 Kyle Furlong skrev:
 
 Oskar Linde wrote:

 if (a !is null || b !is null)

 instead of:

 if (a || b)

I would say that the second construct is much less reliable, maintainable, and safe than the first. Therefore, the type system should disallow the second with a pure boolean type.

I have seen bugs introduced by changing if(!a || !b) into if(a !is null || b !is null)

I would argue that the bug in the first place is coding something like !a || ! b.
 
 And the double negation nature of !is null makes this quite hard to spot 
 (for both me and the one introducing the bug). This contradicts your 
 saying that it makes the code "much more reliable, maintainable and 
 safe". Consider the sentences:
 

Ok lets add some values to a sentence... (let's say a and b are pointers)
 "If a or b"

if 0x01233d3f or 0x533123ff What does that mean in any human language? Exactly nothing!
 
 compared to:
 
 "If a is not nothing or b is not nothing"

if 0x01233d3f isn't 0x00000000 or 0x533123ff isn't 0x00000000
 
 Which one is easier to grasp and get right?

The second one, obviously. The first one has no meaning, second one has obvious and clear meaning, so there is no realy question here...
 
 (!is also takes an extra step when it is parsed by the reader as "not 
 is" and then (in most western languages at least) has to be transformed 
 into "is not")

I don't see that as souch a big problem. And if you think it is the same problem in if(!a || !b). I read it like if not a or not b, and I have to ask myself what not a? a not an elephant? not an apple? not an integer? not null? not not null?
 
 What do you base your statements on? Do you have examples of where 
 (a||b) is less reliable or less safe? Why would it be less maintainable? 

(a||b) is an example of that :)
 It is clearer (less complex) an has a well defined semantic meaning.

It is more complex an doesn't have a well defined semantic meaning. I mean Walter says it does, but the argument 1 is true in C, isn't really an argument. Why then do we have GC, delegates, templates, why then do we have type safety after all? Why out/inout when everything can be done with pointers... It is that way in C shouldn't be an exceptable argument for otherwise superb language like D. (IMHO)
Feb 28 2006
prev sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Kyle Furlong wrote:
 Oskar Linde wrote:
 
 Tom skrev:

 In article <du002m$2pnp$1 digitaldaemon.com>, Ivan Senji says...

 Walter Bright wrote:

 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message

 Walter Bright wrote:



 The problem in all these bool wars so far is I never saw an argument 
 that would be against true booleans (while(BooleanExpression) and 
 all that...).

Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I shut my mouth forever! Tom;

Does pure booleans necessarily mean that other types could not be implicitly convertible to bool? I would love "pure" booleans (not a numeric type, not allowed in arithmetic operations), but I would hate to have to write: if (a !is null || b !is null) instead of: if (a || b)

I would say that the second construct is much less reliable, maintainable, and safe than the first. Therefore, the type system should disallow the second with a pure boolean type.

Ah, you can't explain that to a nonbeliever. :)
Feb 28 2006
prev sibling parent Don Clugston <dac nospam.com.au> writes:
Oskar Linde wrote:
 Tom skrev:
 In article <du002m$2pnp$1 digitaldaemon.com>, Ivan Senji says...
 Walter Bright wrote:
 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
 Walter Bright wrote:



 The problem in all these bool wars so far is I never saw an argument 
 that would be against true booleans (while(BooleanExpression) and all 
 that...).

Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I shut my mouth forever! Tom;

Does pure booleans necessarily mean that other types could not be implicitly convertible to bool? I would love "pure" booleans (not a numeric type, not allowed in arithmetic operations), but I would hate to have to write: if (a !is null || b !is null)

I agree. I think implicit bool in conditionals is important, but in assignments its almost always a bug. eg bool b=false; b++; // either this is hiding a bug, or it's a really confusing way of expressing what you want. In a conditional, there's an implicit "!is null" at the end of every expression. That's why || is not the same as |. This is not the same as implicit conversion from int to bool. And bool-> int is a particularly troublesome conversion. bool b; int x = b; This IS a mistake that I often make (eg, I typed 'b' when it should have been 'c'). Seems to me, that the useful cases Walter keeps talking about (and which I use all the time) can be accommodated, while still catching the sloppy thinking and type mismatch bugs where you get genuine benefit from pure bools.
Feb 28 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Tom" <Tom_member pathlink.com> wrote in message 
news:du049t$2uv2$1 digitaldaemon.com...
 Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I 
 shut my
 mouth forever!

One should be very careful about stepping away from C's implicit promotion rules for a language that aims to be a successor to C. C absolutely *buried* Pascal. Pascal didn't have implicit type conversions. That meant that typical Pascal code was littered with casts. It was ugly, and I'd argue that casting reduces type safety, rather than enhancing it. Pascal played catchup ever since, adopting features of C. Then Pascal++ (i.e. Modula 2) came out, which was promptly buried by C++.
Feb 28 2006
next sibling parent Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Walter Bright skrev:
 "Tom" <Tom_member pathlink.com> wrote in message 
 news:du049t$2uv2$1 digitaldaemon.com...
 Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I 
 shut my
 mouth forever!

One should be very careful about stepping away from C's implicit promotion rules for a language that aims to be a successor to C. C absolutely *buried* Pascal.

I agree. I also find while(5) to be perfectly acceptable. But the problem with placing bool in the integer promotion chain is that it has a semantic difference to the other integer types. - cast from a larger type to bool is defined as x != 0, rater than the analogue of (x&1) for the other integer types. This gives bool slightly different arithmetic properties as I mentioned in a very lengthy post in another place in this thread. (news://news.digitalmars.com:119/dtv65q$1ps2$1 digitaldaemon.com) One such property is the asymmetry: bool never overflows but does underflow. (a++ sets a to true, while a-- flips a's truth value). Another reason not to place bool among the other integer types is that many people expect a bool to be semantically different from integer types. For instance, if you know about boolean algebra, you would expect a+b to be evaluated as a or b... And it is -- almost. The integer promotion unfortunately makes comparisons of truth values shaky (assume a,b boolean): (a+b == true) // here, + becomes xor! vs: bool x = a+b; // here, + behaves as or If bools where removed from the integer promotion chain, the problem with "== true" would go away. Forever. :) /Oskar
Feb 28 2006
prev sibling next sibling parent Tom <Tom_member pathlink.com> writes:
In article <du19j7$15r9$2 digitaldaemon.com>, Walter Bright says...
"Tom" <Tom_member pathlink.com> wrote in message 
news:du049t$2uv2$1 digitaldaemon.com...
 Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I 
 shut my
 mouth forever!

One should be very careful about stepping away from C's implicit promotion rules for a language that aims to be a successor to C. C absolutely *buried* Pascal.

So it's because you think that leaving C bools has more "marketing" and would achieve more "popularity" among future D coders (and most of all, C coders)? Or is it because you don't want C users to feel uncomfortable with D? Just to be a succesor doesn't mean that you can't change the rules, in fact you changed a lot of them so that D compiler isn't a C compiler. OTOH I'm a C coder as well as coder of another languages, and I would asure you that pure boolean consequences wouldn't bother me at all.
Pascal didn't have implicit type conversions. That meant that typical Pascal 
code was littered with casts. It was ugly, and I'd argue that casting 
reduces type safety, rather than enhancing it.

Ok, so pure booleans would end in this kind of cast invasion? If this was the case (which I can't see right now), then I would totally understand you leave bool as it is. But if I can recall someone said in another post, languages as C# has pure booleans implemented: I don't see people crying about C# because of it. It's becomming tremendously popular in fact!
Pascal played catchup ever since, adopting features of C. Then Pascal++ 
(i.e. Modula 2) came out, which was promptly buried by C++. 

I agree that Pascal is dead but don't see D as a future Pascal at all, no matter if it has pure booleans or not. :) As a final thought I realize that this bool fight has more taste-related arguments to defend each position than pragmatic ones. So we WON'T convince Walter 'cos it would be a matter of trying to change people tastes. We know that this is IMPOSSIBLE ;) Thanks for the answers, Tom;
Feb 28 2006
prev sibling next sibling parent "Derek Parnell" <derek psych.ward> writes:
On Tue, 28 Feb 2006 21:42:59 +1100, Walter Bright  
<newshound digitalmars.com> wrote:

 "Tom" <Tom_member pathlink.com> wrote in message
 news:du049t$2uv2$1 digitaldaemon.com...
 Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I
 shut my
 mouth forever!

One should be very careful about stepping away from C's implicit promotion rules for a language that aims to be a successor to C. C absolutely *buried* Pascal. Pascal didn't have implicit type conversions. That meant that typical Pascal code was littered with casts. It was ugly, and I'd argue that casting reduces type safety, rather than enhancing it. Pascal played catchup ever since, adopting features of C. Then Pascal++ (i.e. Modula 2) came out, which was promptly buried by C++.

How would disallowing arithmetic on bools make D like Pascal, or bring about the "littered with casts" scenerio? I just can't see it would change a thing, except help the compiler help coders detect possible errors in their code. -- Derek Parnell Melbourne, Australia
Feb 28 2006
prev sibling next sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:
 "Tom" <Tom_member pathlink.com> wrote in message 
 news:du049t$2uv2$1 digitaldaemon.com...
 
Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I 
shut my
mouth forever!

One should be very careful about stepping away from C's implicit promotion rules for a language that aims to be a successor to C. C absolutely *buried* Pascal.

I don't feel like writing any more about this: but here goes one more... :) Did you read posts by Tom and Derek? I completely agree with them. I came from Pascal to C(actually C++), and there is *no* way for D to become Pascal. No way even if that strange C-like bools are removed and replaced with a more modern bool type. Stepping away from C on this bool story would only encourage everyone to move to D, sticking with C these days isn't a great attractor for C++/Java/C# and probably most other users. on_scope might me an important feature but it isn't the first feature a new user will meet. A new user is likely to encounter bool first, be dissapointed and run away before finding all other cool features. (IMO)
 
 Pascal didn't have implicit type conversions. That meant that typical Pascal 
 code was littered with casts. It was ugly, and I'd argue that casting 
 reduces type safety, rather than enhancing it.

Sure if you have to do it all the time, I agree with most implicit conversions that D has, but not about those for bool.
Feb 28 2006
prev sibling next sibling parent Carlos Santander <csantander619 gmail.com> writes:
Walter Bright escribió:
 
 One should be very careful about stepping away from C's implicit promotion 
 rules for a language that aims to be a successor to C. C absolutely *buried* 
 Pascal.
 
 Pascal didn't have implicit type conversions. That meant that typical Pascal 
 code was littered with casts. It was ugly, and I'd argue that casting 
 reduces type safety, rather than enhancing it.
 
 Pascal played catchup ever since, adopting features of C. Then Pascal++ 
 (i.e. Modula 2) came out, which was promptly buried by C++. 
 
 

That depends on how you code and what you code. I recently wrote a 1600+ LOC Pascal program and I never used a single cast, just because I never needed one. So, that argument is not very strong because it depends on the nature of each situation. -- Carlos Santander Bernal
Feb 28 2006
prev sibling next sibling parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <du19j7$15r9$2 digitaldaemon.com>, Walter Bright says...
Pascal didn't have implicit type conversions. That meant that typical Pascal 
code was littered with casts. It was ugly, and I'd argue that casting 
reduces type safety, rather than enhancing it.

This is untrue. Pascal is a strong-typed language for application programming, so you won't need a single cast (something in Pascal doesn't exist). Pascal was not born for system programming, for this at the time people used assembly (O.S. themselves were writeen in assembly).
Pascal played catchup ever since, adopting features of C. Then Pascal++ 
(i.e. Modula 2) came out, which was promptly buried by C++. 

This is pathethic. When ISO Pascal standard was issued, there wasn't an ISO C. The first ANSI C is from 1989, six years after the Pascal standard. And ANSI-C was a very different language from pre-ANSI-C, for example introducing function prototypes, and changing the function argument passing behaviour, among the other things. So it' *C that has adopted features of Pascal* not the reverse. It's funny that you say that Modula-2 took something from C++, that is not the case. D took modules from Modula-2, instead, and better than the loosy C++ namespace thing. Ciao P.S.: A little time table: 1970 The first Pascal compiler is released 1973 The first Unix kernel is written in C (with the first C compiler available) 1974 The book "PASCAL - User Manual and Report" is published 1978 The book "The C Programming Language" by K&R is published 1980 The first Modula-2 compiler is released 1982 The book "Programming in Modula-2" is published 1983 The ISO Pascal standard is approved 1985 The first edition of "The C++ Programming Language" and the first C++ compiler are released 1989 The ANSI/ISO C standard is approved 1996 The ISO Modula-2 standard is approved 1998 The ISO C++ standard is approved As you can see the first Pascal compiler predates the first C compiler, the first Modula-2 compiler predates the first C++ compiler, Pascal predates C and Modula-2 predates C++. References: http://en.wikipedia.org/wiki/Pascal_programming_language http://en.wikipedia.org/wiki/Modula-2 http://www.cs.inf.ethz.ch/~wirth/ http://en.wikipedia.org/wiki/C_language http://cm.bell-labs.com/cm/cs/who/dmr/chist.html http://en.wikipedia.org/wiki/C%2B%2B
Mar 01 2006
parent Tom <Tom_member pathlink.com> writes:
In article <du3vu2$6ng$1 digitaldaemon.com>, Roberto Mariottini says...
In article <du19j7$15r9$2 digitaldaemon.com>, Walter Bright says...

Pascal played catchup ever since, adopting features of C. Then Pascal++ 
(i.e. Modula 2) came out, which was promptly buried by C++. 


It's funny that you say that Modula-2 took something from C++, that is not the
case.

Mmmh? Or I'm totally wasted or Walter didn't say that? Tom; "Pure Boolean Rules!" :D
Mar 01 2006
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Walter Bright wrote:
 "Tom" <Tom_member pathlink.com> wrote in message 
 news:du049t$2uv2$1 digitaldaemon.com...
 Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I 
 shut my
 mouth forever!

One should be very careful about stepping away from C's implicit promotion rules for a language that aims to be a successor to C. C absolutely *buried* Pascal.

Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what you meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight. What exactly is it in bools that you Walter, want and not want? I already know that the ability to write 'while(1)' as the same as 'while(true)' is one of them, but, anything more? Is the behaviour of having an "implicit promotion" something you want too? If so, promotion from where, from int to bool, or from bool to int? Do you want or not want bool numeric operations to be an error (like boolA / boolB*2) ? -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Mar 02 2006
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Bruno Medeiros wrote:
 Walter Bright wrote:
 "Tom" <Tom_member pathlink.com> wrote in message 
 news:du049t$2uv2$1 digitaldaemon.com...
 Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and 
 I shut my
 mouth forever!

One should be very careful about stepping away from C's implicit promotion rules for a language that aims to be a successor to C. C absolutely *buried* Pascal.

Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what you meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight. What exactly is it in bools that you Walter, want and not want? I already know that the ability to write 'while(1)' as the same as 'while(true)' is one of them, but, anything more? Is the behaviour of having an "implicit promotion" something you want too? If so, promotion from where, from int to bool, or from bool to int? Do you want or not want bool numeric operations to be an error (like boolA / boolB*2) ?

I think one use case that is important is to be able to use bool to connect to C APIs (such as the Windows SDK) that use BOOL (a short). Interestingly, you only need this for extern(C), extern(Windows) declarations. It would be fantastic if there was a way to specify that an extern function is actually a synthetic bool. The ability to say if (p || q) {} instead of if (p !is null || q !is null) {} is important too. I too would like to know if Walter has more.
Mar 02 2006
parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Don Clugston wrote:
 Bruno Medeiros wrote:
 Walter Bright wrote:
 "Tom" <Tom_member pathlink.com> wrote in message 
 news:du049t$2uv2$1 digitaldaemon.com...
 Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one 
 and I shut my
 mouth forever!

One should be very careful about stepping away from C's implicit promotion rules for a language that aims to be a successor to C. C absolutely *buried* Pascal.

Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what you meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight. What exactly is it in bools that you Walter, want and not want? I already know that the ability to write 'while(1)' as the same as 'while(true)' is one of them, but, anything more? Is the behaviour of having an "implicit promotion" something you want too? If so, promotion from where, from int to bool, or from bool to int? Do you want or not want bool numeric operations to be an error (like boolA / boolB*2) ?

I think one use case that is important is to be able to use bool to connect to C APIs (such as the Windows SDK) that use BOOL (a short).

separate from D's bool, no? : alias BOOL short. -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Mar 03 2006
prev sibling parent reply Tom <Tom_member pathlink.com> writes:
In article <du71jc$1e9h$1 digitaldaemon.com>, Bruno Medeiros says...
Walter Bright wrote:
 "Tom" <Tom_member pathlink.com> wrote in message 
 news:du049t$2uv2$1 digitaldaemon.com...
 Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I 
 shut my
 mouth forever!

One should be very careful about stepping away from C's implicit promotion rules for a language that aims to be a successor to C. C absolutely *buried* Pascal.

Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what you meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight. What exactly is it in bools that you Walter, want and not want? I already know that the ability to write 'while(1)' as the same as 'while(true)' is one of them, but, anything more? Is the behaviour of having an "implicit promotion" something you want too? If so, promotion from where, from int to bool, or from bool to int? Do you want or not want bool numeric operations to be an error (like boolA / boolB*2) ?

You should read the latest posts about this stuff (the most with subject "Re: DMD 0.148 release"). It's all said there. By "pure bools" I mean the *purist kind* of boolean type. A boolean type that abstracts us from the implementation. Tom;
Mar 02 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Tom wrote:
 In article <du71jc$1e9h$1 digitaldaemon.com>, Bruno Medeiros says...
 Walter Bright wrote:
 "Tom" <Tom_member pathlink.com> wrote in message 
 news:du049t$2uv2$1 digitaldaemon.com...
 Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I 
 shut my
 mouth forever!

rules for a language that aims to be a successor to C. C absolutely *buried* Pascal.

meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight. What exactly is it in bools that you Walter, want and not want? I already know that the ability to write 'while(1)' as the same as 'while(true)' is one of them, but, anything more? Is the behaviour of having an "implicit promotion" something you want too? If so, promotion from where, from int to bool, or from bool to int? Do you want or not want bool numeric operations to be an error (like boolA / boolB*2) ?

You should read the latest posts about this stuff (the most with subject "Re: DMD 0.148 release"). It's all said there. By "pure bools" I mean the *purist kind* of boolean type. A boolean type that abstracts us from the implementation.

Sorry, that's still not clear. Bruno is right, terms like "pure bools" or "purist bools" are vague, you can't expect everyone to know what you mean. For example: do you want "&" to be legal for bool types, or just "&&"? (they mean very different things for integers). "&" normally means "bitwise and", but a pure bool doesn't have any bits. Is it legal to cast from a bool to some other type?
 A boolean type that abstracts us from the implementation.

No abstraction is perfect. Does a bool have a defined bit representation? (If you say 'no' to this, then I don't think a bool could be used in an extern function, you'd always have to convert it to int or something). You need a comprehensive list of which operations are legal, and which are not.
Mar 03 2006
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Don Clugston wrote:
 Tom wrote:
 In article <du71jc$1e9h$1 digitaldaemon.com>, Bruno Medeiros says...
 Walter Bright wrote:
 "Tom" <Tom_member pathlink.com> wrote in message 
 news:du049t$2uv2$1 digitaldaemon.com...
 Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one 
 and I shut my
 mouth forever!

promotion rules for a language that aims to be a successor to C. C absolutely *buried* Pascal.

you meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight. What exactly is it in bools that you Walter, want and not want? I already know that the ability to write 'while(1)' as the same as 'while(true)' is one of them, but, anything more? Is the behaviour of having an "implicit promotion" something you want too? If so, promotion from where, from int to bool, or from bool to int? Do you want or not want bool numeric operations to be an error (like boolA / boolB*2) ?

You should read the latest posts about this stuff (the most with subject "Re: DMD 0.148 release"). It's all said there. By "pure bools" I mean the *purist kind* of boolean type. A boolean type that abstracts us from the implementation.

Sorry, that's still not clear. Bruno is right, terms like "pure bools" or "purist bools" are vague, you can't expect everyone to know what you mean. For example: do you want "&" to be legal for bool types, or just "&&"? (they mean very different things for integers). "&" normally means "bitwise and", but a pure bool doesn't have any bits. Is it legal to cast from a bool to some other type? > A boolean type that abstracts us from the implementation. No abstraction is perfect. Does a bool have a defined bit representation? (If you say 'no' to this, then I don't think a bool could be used in an extern function, you'd always have to convert it to int or something). You need a comprehensive list of which operations are legal, and which are not.

I tend to want a boolean that is an operand of the boolean algebra and nothing else. So it is either true or false, independant of implementation, integer operations are illegal, and it cant be cast to anything.
Mar 03 2006
prev sibling next sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Don Clugston wrote:
 Tom wrote:
 In article <du71jc$1e9h$1 digitaldaemon.com>, Bruno Medeiros says...
 Walter Bright wrote:
 "Tom" <Tom_member pathlink.com> wrote in message 
 news:du049t$2uv2$1 digitaldaemon.com...
 Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one 
 and I shut my
 mouth forever!

promotion rules for a language that aims to be a successor to C. C absolutely *buried* Pascal.

you meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight. What exactly is it in bools that you Walter, want and not want? I already know that the ability to write 'while(1)' as the same as 'while(true)' is one of them, but, anything more? Is the behaviour of having an "implicit promotion" something you want too? If so, promotion from where, from int to bool, or from bool to int? Do you want or not want bool numeric operations to be an error (like boolA / boolB*2) ?

You should read the latest posts about this stuff (the most with subject "Re: DMD 0.148 release"). It's all said there. By "pure bools" I mean the *purist kind* of boolean type. A boolean type that abstracts us from the implementation.

Sorry, that's still not clear. Bruno is right, terms like "pure bools" or "purist bools" are vague, you can't expect everyone to know what you mean. For example: do you want "&" to be legal for bool types, or just "&&"? (they mean very different things for integers). "&" normally means "bitwise and", but a pure bool doesn't have any bits. Is it legal to cast from a bool to some other type? > A boolean type that abstracts us from the implementation. No abstraction is perfect. Does a bool have a defined bit representation? (If you say 'no' to this, then I don't think a bool could be used in an extern function, you'd always have to convert it to int or something). You need a comprehensive list of which operations are legal, and which are not.

Exactly, the "pure bools" must be defined by a set of language behaviors. Derek made a post some time ago with one such definition (news://news.digitalmars.com:119/14shfnb64x5o2.17cec6fac7wnu.dlg 40tude.net). However, the problem is, and the reason I opened this thread, that in the previous discussion people started getting lost in a too vague or incongruous debate of "pure bools" vs. being able to use "while(1)" and implicit conversions and whatnot (arguing about things that are not on the same level). What I'm trying to say is, that of that set of bool behaviors, it is not an all or nothing situation, it is a gradient of behaviors. Just a part of them can be implemented, and if all Walter wants is the ability to do "while(1)" or 'implicit conversion of integers to bool' (which are the only counter-points I've seen so far), then there is still a lot of other things that can me made to improve bool: We could have: * Conditional expressions should be of type bool * Integers can be implicitly converted to bool, as Walter wants. (where 0 is false, the rest is true). This allows for "while(1)" . * Pointer and references can be implicitly converted too (where null is false, the rest is true). This allows for "if(objFoo)" . * No numeric operations are allowed on bool, just boolean operations. * bool can only be explicitly cast to a numeric type. * Regardless of bool implementation, it has only two abstract states: true or false, and conversions from int should be aware of that. For instance this should 'then': if (2==true) writefln("then"); // doesnt "then" :( It won't be the "purest" of bools (like Java or C# or other languages), because of the second feature, but it's still a lot better than what we have. Walter what's your take? Do you have any problem with any of these behaviors? -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Mar 03 2006
parent reply Tom <Tom_member pathlink.com> writes:
In article <du9cnl$2h9j$3 digitaldaemon.com>, Bruno Medeiros says...
Don Clugston wrote:
 Tom wrote:
 In article <du71jc$1e9h$1 digitaldaemon.com>, Bruno Medeiros says...
 Walter Bright wrote:
 "Tom" <Tom_member pathlink.com> wrote in message 
 news:du049t$2uv2$1 digitaldaemon.com...
 Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one 
 and I shut my
 mouth forever!

promotion rules for a language that aims to be a successor to C. C absolutely *buried* Pascal.

you meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight. What exactly is it in bools that you Walter, want and not want? I already know that the ability to write 'while(1)' as the same as 'while(true)' is one of them, but, anything more? Is the behaviour of having an "implicit promotion" something you want too? If so, promotion from where, from int to bool, or from bool to int? Do you want or not want bool numeric operations to be an error (like boolA / boolB*2) ?

You should read the latest posts about this stuff (the most with subject "Re: DMD 0.148 release"). It's all said there. By "pure bools" I mean the *purist kind* of boolean type. A boolean type that abstracts us from the implementation.

Sorry, that's still not clear. Bruno is right, terms like "pure bools" or "purist bools" are vague, you can't expect everyone to know what you mean.


[snip]
Derek made a post some time ago with one such definition 
(news://news.digitalmars.com:119/14shfnb64x5o2.17cec6fac7wnu.dlg 40tude.net).

And that is exactly what I meant when I said that you should read the latest posts on the stuff :) Tom;
Mar 03 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Tom wrote:
 In article <du9cnl$2h9j$3 digitaldaemon.com>, Bruno Medeiros says...
 Don Clugston wrote:
 Tom wrote:
 In article <du71jc$1e9h$1 digitaldaemon.com>, Bruno Medeiros says...
 Walter Bright wrote:
 "Tom" <Tom_member pathlink.com> wrote in message 
 news:du049t$2uv2$1 digitaldaemon.com...
 Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one 
 and I shut my
 mouth forever!

promotion rules for a language that aims to be a successor to C. C absolutely *buried* Pascal.

you meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight. What exactly is it in bools that you Walter, want and not want? I already know that the ability to write 'while(1)' as the same as 'while(true)' is one of them, but, anything more? Is the behaviour of having an "implicit promotion" something you want too? If so, promotion from where, from int to bool, or from bool to int? Do you want or not want bool numeric operations to be an error (like boolA / boolB*2) ?

subject "Re: DMD 0.148 release"). It's all said there. By "pure bools" I mean the *purist kind* of boolean type. A boolean type that abstracts us from the implementation.

Bruno is right, terms like "pure bools" or "purist bools" are vague, you can't expect everyone to know what you mean.


[snip]
 Derek made a post some time ago with one such definition 
 (news://news.digitalmars.com:119/14shfnb64x5o2.17cec6fac7wnu.dlg 40tude.net).

And that is exactly what I meant when I said that you should read the latest posts on the stuff :)

And if you read that post, you will find that Derek said: ** It can be explicitly cast to an integer such that false is 0, and true is 1. whereas Kyle said: integer operations are illegal, and it cant be cast to anything. So there are at least four types of bool being discussed. Probably more. And at least two can be called "pure bool". (a) the existing bool (b) Bruno and I are in here somewhere, and are not necessarily the same. (c) Derek (d) Kyle Right now, (a) and (c) are the only ones which are clearly defined.
Mar 03 2006
next sibling parent reply xs0 <xs0 xs0.com> writes:
Don Clugston wrote:
 Tom wrote:
 In article <du9cnl$2h9j$3 digitaldaemon.com>, Bruno Medeiros says...
 Don Clugston wrote:
 Tom wrote:
 In article <du71jc$1e9h$1 digitaldaemon.com>, Bruno Medeiros says...
 Walter Bright wrote:
 "Tom" <Tom_member pathlink.com> wrote in message 
 news:du049t$2uv2$1 digitaldaemon.com...
 Yes, PLEASE, WHY?? Just ONE argument against pure bools, only 
 one and I shut my
 mouth forever!

promotion rules for a language that aims to be a successor to C. C absolutely *buried* Pascal.

what you meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight. What exactly is it in bools that you Walter, want and not want? I already know that the ability to write 'while(1)' as the same as 'while(true)' is one of them, but, anything more? Is the behaviour of having an "implicit promotion" something you want too? If so, promotion from where, from int to bool, or from bool to int? Do you want or not want bool numeric operations to be an error (like boolA / boolB*2) ?

subject "Re: DMD 0.148 release"). It's all said there. By "pure bools" I mean the *purist kind* of boolean type. A boolean type that abstracts us from the implementation.

Bruno is right, terms like "pure bools" or "purist bools" are vague, you can't expect everyone to know what you mean.


[snip]
 Derek made a post some time ago with one such definition 
 (news://news.digitalmars.com:119/14shfnb64x5o2.17cec6fac7wnu.dlg 40tude.net). 

And that is exactly what I meant when I said that you should read the latest posts on the stuff :)

And if you read that post, you will find that Derek said: ** It can be explicitly cast to an integer such that false is 0, and true is 1. whereas Kyle said: integer operations are illegal, and it cant be cast to anything. So there are at least four types of bool being discussed. Probably more. And at least two can be called "pure bool". (a) the existing bool (b) Bruno and I are in here somewhere, and are not necessarily the same. (c) Derek (d) Kyle Right now, (a) and (c) are the only ones which are clearly defined.

Hmm, how about an expansion of (d): 1) still allow implicit casts to bool from any type, as in - value != 0 - obj_ref !is null - pointer !is null - array.ptr !is null - !struct.opEquals(0) // does this work now? 2) forbid casts from bool to anything else (even explicit; besides "foo?1:0" is shorter and more obvious than "cast(int)foo") 3) when an expression involves a bool operand, all other operands get converted to bool 4) forbid all operators on bools, except ==, !=, &&, ||, &, |, and !. (& and | don't short-circuit evaluation, but are otherwise equivalent to && and ||). Then, the purists should be satisfied, because the only operations allowed are the logic ones, and true and false don't have a numeric representation. There is a true/false representation of everything else, though, allowing all the short forms we like, like while(1) if (foo && foo.bar()) if (refA || refB) xs0
Mar 03 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
xs0 wrote:
 
 Hmm, how about an expansion of (d):
 
 1) still allow implicit casts to bool from any type, as in
 - value != 0
 - obj_ref !is null
 - pointer !is null
 - array.ptr !is null
 - !struct.opEquals(0) // does this work now?
 
 2) forbid casts from bool to anything else (even explicit; besides 
 "foo?1:0" is shorter and more obvious than "cast(int)foo")
 
 3) when an expression involves a bool operand, all other operands get 
 converted to bool
 
 4) forbid all operators on bools, except ==, !=, &&, ||, &, |, and !. (& 
 and | don't short-circuit evaluation, but are otherwise equivalent to && 
 and ||).
 
 
 Then, the purists should be satisfied, because the only operations 
 allowed are the logic ones, and true and false don't have a numeric 
 representation.
 

Ok, I (as a bool purist) will not be satisfied with that & and | part. & and | are not logic operations but bit operations.
 There is a true/false representation of everything else, though, 
 allowing all the short forms we like, like
 
 while(1)
 if (foo && foo.bar())
 if (refA || refB)
 

Yuck, but I would agree with it as long as conditions have to be booleans. I know it isn't a perfect world and although I would never use the above, it would still be better than what we have now (as long as all the other conditions are satisified).
Mar 03 2006
parent reply xs0 <xs0 xs0.com> writes:
Ivan Senji wrote:
 xs0 wrote:
 4) forbid all operators on bools, except ==, !=, &&, ||, &, |, and !. 
 (& and | don't short-circuit evaluation, but are otherwise equivalent 
 to && and ||).


 Then, the purists should be satisfied, because the only operations 
 allowed are the logic ones, and true and false don't have a numeric 
 representation.

Ok, I (as a bool purist) will not be satisfied with that & and | part. & and | are not logic operations but bit operations.

They are bitwise operations on integers, because that's what they're defined to be. We're free to define them to do something else on booleans, which I propose to be [what I said above]. BTW, even Java, which has a really purist boolean implementation, uses those for exactly the stated purpose (and even calls them "logical operators", while && and || are "conditional-and" and "-or" :) http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.5
 There is a true/false representation of everything else, though, 
 allowing all the short forms we like, like

 while(1)
 if (foo && foo.bar())
 if (refA || refB)

Yuck, but I would agree with it as long as conditions have to be booleans. I know it isn't a perfect world and although I would never use the above, it would still be better than what we have now (as long as all the other conditions are satisified).

I used to think so too, until I was forced to code in Java :) Even though I don't mind typing something as simple as if (a!=null) the verbosity of longer expressions really annoys the heck out of me. Now, I prefer
 if (a && b && c && d) // check for nulls
    ...

to
 if (a!=null && b!=null && c!=null && d!=null)
    ...

or D's even verboser
 if (a !is null && b !is null && c !is null || d !is null)
    ...

Note how the vars that are being tested get lost in there.. BTW, did you notice the last line is not equivalent? :) xs0
Mar 03 2006
parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
xs0 wrote:
 They are bitwise operations on integers, because that's what they're 
 defined to be. We're free to define them to do something else on 
 booleans, which I propose to be [what I said above].

Ok, now I understand what you're saying. But to have that behaviour we need very very different bools.
 
 BTW, even Java, which has a really purist boolean implementation, uses 
 those for exactly the stated purpose (and even calls them "logical 
 operators", while && and || are "conditional-and" and "-or" :)
 
 http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.5 
 

Thanks for the link.
 
 There is a true/false representation of everything else, though, 
 allowing all the short forms we like, like

 while(1)
 if (foo && foo.bar())
 if (refA || refB)

Yuck, but I would agree with it as long as conditions have to be booleans. I know it isn't a perfect world and although I would never use the above, it would still be better than what we have now (as long as all the other conditions are satisified).

I used to think so too, until I was forced to code in Java :)

I also coded in Java and never found this to be a problem :)
 Even though I don't mind typing something as simple as
 
 if (a!=null)
 
 the verbosity of longer expressions really annoys the heck out of me. 
 Now, I prefer
 
  > if (a && b && c && d) // check for nulls

But what is going on behind the scene if a,b,c,d are ints or ponters, conversions to bools? I still don't get it how logic && operator can be aplied to integers. What is 5 && 3? (Except two numbers: 5,3.) It has no value regarding truth. It is neither true nor false.
  >    ...
 
 to
 
  > if (a!=null && b!=null && c!=null && d!=null)

better.... :)
  >    ...
 
 or D's even verboser
 
  > if (a !is null && b !is null && c !is null || d !is null)

the best :) Except that little bug caused deliberately by you :) Formated this way: if( (a !is null) && (b !is null) && (c !is null) && (d !is null) ) it is alittle bit more clear.
Mar 03 2006
parent reply xs0 <xs0 xs0.com> writes:
Ivan Senji wrote:
 xs0 wrote:

 I used to think so too, until I was forced to code in Java :) 

I also coded in Java and never found this to be a problem :)

Sure, it has an easy "workaround", but like I said, I don't think the added verbosity helps, rather the opposite.
 Even though I don't mind typing something as simple as

 if (a!=null)

 the verbosity of longer expressions really annoys the heck out of me. 
 Now, I prefer

  > if (a && b && c && d) // check for nulls

But what is going on behind the scene if a,b,c,d are ints or ponters, conversions to bools? I still don't get it how logic && operator can be aplied to integers. What is 5 && 3? (Except two numbers: 5,3.) It has no value regarding truth. It is neither true nor false.

Well, I believe that is just a matter of education/documentation. As much as you need to know that && will short-circuit, you also need to know that it will evaluate the operands as booleans. And, while 3 or 5 are definitely neither true nor false in themselves, one can certainly define a conversion between them and booleans.. It's somewhat like Java's evaluation of "abc"+123. It's implied that 123 will be converted to a string form, and no-one seems to mind, even though there is no implicit relationship between numbers and strings (no, there isn't; 123 as a string could just as easily be "321"(*) or "123.0000000000000", "onetwothree" or "WARNING: auto-conversion of 123 of type int to java.lang.String").. Would you also prefer "abc"+String.valueOf(123) or even // hey, who ever heard of a sum of strings? StringBuffer sb=new StringBuffer(); sb.append("abc"); sb.append(123); return sb.toString(); ? I mean, compared to almost everything else in programming, is it really so hard to grasp/learn/remember/know/whatever that 0 and null evaluate to false, while everything else evaluates to true? xs0 *) this could be called a little-endian string :)
Mar 06 2006
parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
xs0 wrote:
 Well, I believe that is just a matter of education/documentation. As 
 much as you need to know that && will short-circuit, you also need to 
 know that it will evaluate the operands as booleans. And, while 3 or 5 
 are definitely neither true nor false in themselves, one can certainly 
 define a conversion between them and booleans..

Sure, only question: does it makes sense to do that? Judging by the mayority of opinions it does make sense.
 
 It's somewhat like Java's evaluation of "abc"+123. It's implied that 123 
 will be converted to a string form, and no-one seems to mind, even 
 though there is no implicit relationship between numbers and strings 
 (no, there isn't; 123 as a string could just as easily be "321"(*) or 
 "123.0000000000000", "onetwothree" or "WARNING: auto-conversion of 123 
 of type int to java.lang.String").. Would you also prefer
 
 "abc"+String.valueOf(123)

it could be like in C#(if I remember correctly): "abc" + 123.ToString(); Well i certainly don't miss this aspect of Java in D. There is a good way (maybe a little longer) to do that in D.
 
 or even
 
 // hey, who ever heard of a sum of strings?
 StringBuffer sb=new StringBuffer();
 sb.append("abc");
 sb.append(123);
 return sb.toString();
 
 ?

No I wouldn't prefer these. I prefer format("abc",123); :)
 
 I mean, compared to almost everything else in programming, is it really 
 so hard to grasp/learn/remember/know/whatever that 0 and null evaluate 
 to false, while everything else evaluates to true?

No, the problem is and never was in neither grasping nor learning nor remembering this behavior. The problem was that some people see booleans as mathematicians, and in math bools can only be true or false, and can only be a result of operations like <,==,>=, !is, ...
 
 
 xs0
 
 *) this could be called a little-endian string :)

Cool!
Mar 06 2006
prev sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
xs0 wrote:
 Don Clugston wrote:
 And if you read that post, you will find that Derek said:

 ** It can be explicitly cast to an integer such that false is 0, and 
 true is 1.

 whereas Kyle said:

 integer operations are illegal, and it cant be cast to anything.

 So there are at least four types of bool being discussed. Probably more.
 And at least two can be called "pure bool".
 (a) the existing bool
 (b) Bruno and I are in here somewhere, and are not necessarily the same.
 (c) Derek
 (d) Kyle

 Right now, (a) and (c) are the only ones which are clearly defined.

Hmm, how about an expansion of (d):

Yes, this is very similar to the definition I have suggested. I think this is a good compromise:
 1) still allow implicit casts to bool from any type, as in
 - value != 0
 - obj_ref !is null
 - pointer !is null
 - array.ptr !is null
 - !struct.opEquals(0) // does this work now?

This would mean that we would keep if(a && b) and also that the type of any conditional could be defined as bool. But it would also mean that you could write bool b = 5; I guess.
 2) forbid casts from bool to anything else (even explicit; besides 
 "foo?1:0" is shorter and more obvious than "cast(int)foo")

I can live with explicit cast both being allowed and not. I don't see it as an important detail. The important part is to disallow implicit casts from bool to any type.
 3) when an expression involves a bool operand, all other operands get 
 converted to bool

This is the logical conclusion from 1) and 2).
 4) forbid all operators on bools, except ==, !=, &&, ||, &, |, and !. (& 
 and | don't short-circuit evaluation, but are otherwise equivalent to && 
 and ||).

For consistency, ~ should be supported too. And ^ too of course. /Oskar
Mar 03 2006
parent xs0 <xs0 xs0.com> writes:
Oskar Linde wrote:
 xs0 wrote:
 
 Don Clugston wrote:

 whereas Kyle said:

 integer operations are illegal, and it cant be cast to anything.

 So there are at least four types of bool being discussed. Probably more.
 And at least two can be called "pure bool".
 ...
 (d) Kyle

 Right now, (a) and (c) are the only ones which are clearly defined.

Hmm, how about an expansion of (d):

Yes, this is very similar to the definition I have suggested. I think this is a good compromise:
 1) still allow implicit casts to bool from any type, as in
 - value != 0
 - obj_ref !is null
 - pointer !is null
 - array.ptr !is null
 - !struct.opEquals(0) // does this work now?

This would mean that we would keep if(a && b) and also that the type of any conditional could be defined as bool. But it would also mean that you could write bool b = 5; I guess.

Yup, but I think it's good that with bool b=expr; if (b) { } the if statement's condition always evaluates exactly the same as with if (expr) { } even though the "=5" case indeed looks somewhat odd. It should be declared bad style to write that :)
 2) forbid casts from bool to anything else (even explicit; besides 
 "foo?1:0" is shorter and more obvious than "cast(int)foo")

I can live with explicit cast both being allowed and not. I don't see it as an important detail. The important part is to disallow implicit casts from bool to any type.

Well, if you allow/provide a cast, it's most probably going to be to 0 and 1, which somewhat implies sort-of equivalence between 1 and true, and that's probably not a good thing.. it would mean that it'd still be possible to do arithmetics with booleans, which I believe should be avoided.
 4) forbid all operators on bools, except ==, !=, &&, ||, &, |, and !. 
 (& and | don't short-circuit evaluation, but are otherwise equivalent 
 to && and ||).

For consistency, ~ should be supported too. And ^ too of course.

Well, we have ! and != already, I'm not sure what there's to gain from having duplicates? xs0
Mar 03 2006
prev sibling parent Tom <Tom_member pathlink.com> writes:
In article <du9ff8$2ltg$1 digitaldaemon.com>, Don Clugston says...
Tom wrote:
 In article <du9cnl$2h9j$3 digitaldaemon.com>, Bruno Medeiros says...
 Don Clugston wrote:
 Tom wrote:
 In article <du71jc$1e9h$1 digitaldaemon.com>, Bruno Medeiros says...
 Walter Bright wrote:
 "Tom" <Tom_member pathlink.com> wrote in message 
 news:du049t$2uv2$1 digitaldaemon.com...
 Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one 
 and I shut my
 mouth forever!

promotion rules for a language that aims to be a successor to C. C absolutely *buried* Pascal.

you meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight. What exactly is it in bools that you Walter, want and not want? I already know that the ability to write 'while(1)' as the same as 'while(true)' is one of them, but, anything more? Is the behaviour of having an "implicit promotion" something you want too? If so, promotion from where, from int to bool, or from bool to int? Do you want or not want bool numeric operations to be an error (like boolA / boolB*2) ?

subject "Re: DMD 0.148 release"). It's all said there. By "pure bools" I mean the *purist kind* of boolean type. A boolean type that abstracts us from the implementation.

Bruno is right, terms like "pure bools" or "purist bools" are vague, you can't expect everyone to know what you mean.


[snip]
 Derek made a post some time ago with one such definition 
 (news://news.digitalmars.com:119/14shfnb64x5o2.17cec6fac7wnu.dlg 40tude.net).

And that is exactly what I meant when I said that you should read the latest posts on the stuff :)

And if you read that post, you will find that Derek said: ** It can be explicitly cast to an integer such that false is 0, and true is 1. whereas Kyle said: integer operations are illegal, and it cant be cast to anything. So there are at least four types of bool being discussed. Probably more. And at least two can be called "pure bool". (a) the existing bool (b) Bruno and I are in here somewhere, and are not necessarily the same. (c) Derek (d) Kyle Right now, (a) and (c) are the only ones which are clearly defined.

You are right. So lets just call (c) "Derek's Bool". And now that the definition has been made, I vote for "Derek's Bool" :D Tom;
Mar 03 2006
prev sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Don Clugston wrote:
 You should read the latest posts about this stuff (the most with 
 subject "Re:
 DMD 0.148 release"). It's all said there. By "pure bools" I mean the 
 *purist
 kind* of boolean type. A boolean type that abstracts us from the 
 implementation.

Sorry, that's still not clear. Bruno is right, terms like "pure bools" or "purist bools" are vague, you can't expect everyone to know what you mean. For example: do you want "&" to be legal for bool types, or just "&&"?

Just &&.
 (they mean very different things for integers). "&" normally means 
 "bitwise and", but a pure bool doesn't have any bits.
 Is it legal to cast from a bool to some other type?

I'm not against casting but implicit conversions are bad.
 
  > A boolean type that abstracts us from the implementation.
 
 No abstraction is perfect. Does a bool have a defined bit 
 representation? (If you say 'no' to this, then I don't think a bool 
 could be used in an extern function, you'd always have to convert it to 
 int or something).

I think D ABI should define an internal representation, but it should be abstracted from the user, so that the user doesn't have tok know anything about it. You make a good point about passing bool to extern functions, but one could argue that even right now you are calling extern functions using bools with a couple assumptions in mind. For example that the function uses 0==false and true==everything but 0. But that doesn't have to be true.
Mar 03 2006
parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Ivan Senji wrote:
 Don Clugston wrote:
 Sorry, that's still not clear.
 Bruno is right, terms like "pure bools" or "purist bools" are vague, 
 you can't expect everyone to know what you mean.

 For example: do you want "&" to be legal for bool types, or just "&&"?

Just &&.

Why? Ever heard of boolean algebra? Why should &,|,^,~ not be defined and allowed for bool? It would be problematic and inconsistent not having non-short-circuit operators for booleans.
 (they mean very different things for integers). "&" normally means 
 "bitwise and", but a pure bool doesn't have any bits.
 Is it legal to cast from a bool to some other type?

I'm not against casting but implicit conversions are bad.

Do you mean that all implicit conversions are bad? Are the integer promotion rules bad? /Oskar
Mar 03 2006
parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Oskar Linde wrote:
 Ivan Senji wrote:
 
 Don Clugston wrote:

 Sorry, that's still not clear.
 Bruno is right, terms like "pure bools" or "purist bools" are vague, 
 you can't expect everyone to know what you mean.

 For example: do you want "&" to be legal for bool types, or just "&&"?

Just &&.

Why? Ever heard of boolean algebra?

Ever heard of logic operators && and ||? That is what they are for.
 Why should &,|,^,~ not be defined 
 and allowed for bool? It would be problematic and inconsistent not 
 having non-short-circuit operators for booleans.

I learned from xs0's reply that Java uses &,| for non-short-circuit evaluation when arguments are of type bool. As D doesn't have a bool in the Java meaning I don't think making & anything but bitwise operator makes sense.
 
 (they mean very different things for integers). "&" normally means 
 "bitwise and", but a pure bool doesn't have any bits.
 Is it legal to cast from a bool to some other type?

I'm not against casting but implicit conversions are bad.

Do you mean that all implicit conversions are bad? Are the integer promotion rules bad?

Ofcourse not. But with bools yes. Do you think: bool b = 5; would be a good thing? int x = b/3; would be a good thing?
Mar 03 2006
parent reply Oskar Linde <olREM OVEnada.kth.se> writes:
Ivan Senji wrote:

 Oskar Linde wrote:
 Ivan Senji wrote:
 
 Don Clugston wrote:

 Sorry, that's still not clear.
 Bruno is right, terms like "pure bools" or "purist bools" are vague,
 you can't expect everyone to know what you mean.

 For example: do you want "&" to be legal for bool types, or just "&&"?

Just &&.

Why? Ever heard of boolean algebra?

Ever heard of logic operators && and ||? That is what they are for.

&& and || controls the program flow. They are not algebraic operators. &,|,~,^ are real operators that also maps directly onto machine instructions on most cpu architectures. Their meaning would be well defined for bools. && and || requires branching and are therefore much less efficient (even though this can be optimized away in many cases). Also, not allowing ^ for bools would mean that code that reads a^b today would have to be rewritten as: (a && !b) || (!a && b).
 Why should &,|,^,~ not be defined
 and allowed for bool? It would be problematic and inconsistent not
 having non-short-circuit operators for booleans.

I learned from xs0's reply that Java uses &,| for non-short-circuit evaluation when arguments are of type bool. As D doesn't have a bool in the Java meaning I don't think making & anything but bitwise operator makes sense.

Huh? There have been regular discussions on the D newsgroups about bool since atleast 2001. Almost all threads about this have people arguing for the introduction of a logical (as opposed to the current numerical) bool type similar (not necessarily identical) to the Java boolean. Isn't this what we are discussing here too?
 (they mean very different things for integers). "&" normally means
 "bitwise and", but a pure bool doesn't have any bits.
 Is it legal to cast from a bool to some other type?

I'm not against casting but implicit conversions are bad.

Do you mean that all implicit conversions are bad? Are the integer promotion rules bad?

Ofcourse not. But with bools yes.

I read your statement as meaning that all implicit conversions are bad. I was merely interested in why you thought so. :) /Oskar
Mar 03 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Oskar Linde wrote:
 && and || controls the program flow. 

If's and while's containing them control program flow (or I didn't get something right?)
 They are not algebraic operators.

They are logic operators. (Ok algebraic if we are talking about Boolean algebra).
 &,|,~,^ are real operators that also maps directly onto machine
 instructions on most cpu architectures. 

Sure they are, and I use them all the time on ints.
 Their meaning would be well defined
 for bools. 

Not really: bool a = //somehow 2 bool b = //somehow 4 a && b == true && true == true a & b == 0x0010 & 0x0100 == 0x0000 == false, I mean they would work but only if true == always 1 and false == always 0.
 && and || requires branching and are therefore much less
 efficient (even though this can be optimized away in many cases). 
 
 Also, not allowing ^ for bools would mean that code that reads a^b today
 would have to be rewritten as:
 
 (a && !b) || (!a && b).
 

Oops, forgot about that one, so ^ can stay :)
 
Why should &,|,^,~ not be defined
and allowed for bool? It would be problematic and inconsistent not
having non-short-circuit operators for booleans.

I learned from xs0's reply that Java uses &,| for non-short-circuit evaluation when arguments are of type bool. As D doesn't have a bool in the Java meaning I don't think making & anything but bitwise operator makes sense.

Huh? There have been regular discussions on the D newsgroups about bool since atleast 2001.

Tell me about it, I think it is an neverending topic for D. Maybe even if Walter got bools 'right' some people would be complaining.
 Almost all threads about this have people arguing for
 the introduction of a logical (as opposed to the current numerical) bool
 type similar (not necessarily identical) to the Java boolean. Isn't this
 what we are discussing here too?

I think so. In the paragraf you replyed to I was just trying to say that having &,| and ^ for bools only has meaning f they are strict logic bools and not numeric.
(they mean very different things for integers). "&" normally means
"bitwise and", but a pure bool doesn't have any bits.
Is it legal to cast from a bool to some other type?

I'm not against casting but implicit conversions are bad.

Do you mean that all implicit conversions are bad? Are the integer promotion rules bad?

Ofcourse not. But with bools yes.

I read your statement as meaning that all implicit conversions are bad. I was merely interested in why you thought so. :)

Well, I think I would be crazy to think that ;)
Mar 03 2006
parent reply Oskar Linde <olREM OVEnada.kth.se> writes:
Ivan Senji wrote:

 Oskar Linde wrote:
 && and || controls the program flow.

If's and while's containing them control program flow (or I didn't get something right?)

They control program flow by themselves too: my_if() && (my_then(),1) || my_else(); Is equivalent to: if (my_if()) my_then(); else my_else();
 &,|,~,^ are real operators that also maps directly onto machine
 instructions on most cpu architectures.

Sure they are, and I use them all the time on ints.
 Their meaning would be well defined
 for bools.

Not really: bool a = //somehow 2 bool b = //somehow 4 a && b == true && true == true a & b == 0x0010 & 0x0100 == 0x0000 == false, I mean they would work but only if true == always 1 and false == always 0.

We all seem to be talking about different kinds of bool :). [snip]
 In the paragraf you replyed to I was just trying to say that having &,|
 and ^ for bools only has meaning f they are strict logic bools and not
 numeric.

I see. I was talking about logical bools. Btw, the current bool (and C99 _Bool, C++ bool) is defined to be either 1 or 0. Without sidestepping the type system there is no way to make a bool take any other value. This means that both numeric operators and bitwise operator are well defined. A bool can never somehow be 2 or somehow be 4. Assigning x to a bool makes an implicit (x!=0). Another numeric boolean representation where the least significant bit defines the truth state would also work with bit operations. The bool you seem to be talking about is one where any numeric value != 0 would represent true? /Oskar
Mar 04 2006
parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Oskar Linde wrote:
 Ivan Senji wrote:
 
 
Oskar Linde wrote:

&& and || controls the program flow.

If's and while's containing them control program flow (or I didn't get something right?)

They control program flow by themselves too: my_if() && (my_then(),1) || my_else(); Is equivalent to: if (my_if()) my_then(); else my_else();

Cool, I am never going to use if,then,else again ;) This is so much cooler :)
 
&,|,~,^ are real operators that also maps directly onto machine
instructions on most cpu architectures.

Sure they are, and I use them all the time on ints.
Their meaning would be well defined
for bools.

Not really: bool a = //somehow 2 bool b = //somehow 4 a && b == true && true == true a & b == 0x0010 & 0x0100 == 0x0000 == false, I mean they would work but only if true == always 1 and false == always 0.

We all seem to be talking about different kinds of bool :).

That is true.
 
 [snip]
 
 
In the paragraf you replyed to I was just trying to say that having &,|
and ^ for bools only has meaning f they are strict logic bools and not
numeric.

I see. I was talking about logical bools. Btw, the current bool (and C99 _Bool, C++ bool) is defined to be either 1 or 0. Without sidestepping the type system there is no way to make a bool take any other value. This means that both numeric operators and bitwise operator are well defined. A bool can never somehow be 2 or somehow be 4. Assigning x to a bool makes an implicit (x!=0). Another numeric boolean representation where the least significant bit defines the truth state would also work with bit operations.

I did some teseting and it seems to be true. Then my only objection would be if and while taking non boolean arguments, or put differently implicit conversions from bool. But I'm going to stop complaining now and learn to continue to live with how it is now...
 
 The bool you seem to be talking about is one where any numeric value != 0
 would represent true?
 

Not really, I'm talking about an i'dont-care-what-it-is bool. :)
Mar 04 2006
prev sibling parent reply Miles <_______ _______.____> writes:
(your KNode is breaking threads!)

Oskar Linde wrote:
 Also, not allowing ^ for bools would mean that code that reads a^b today
 would have to be rewritten as:
 
 (a && !b) || (!a && b).

Err... what you want is just: a != b
Mar 04 2006
parent reply Oskar Linde <olREM OVEnada.kth.se> writes:
Miles wrote:

 (your KNode is breaking threads!)

I apologize. I didn't notice that KNode put a single group followup-to-header instead of keeping cross-posting (I assume this is what you are referring to). I will remove the follow-up from this post, but I think KNodes behavior is correct. It is stupid to keep cross-posting this discussion on the two probably most read D newsgroups.
 Oskar Linde wrote:
 Also, not allowing ^ for bools would mean that code that reads a^b today
 would have to be rewritten as:
 
 (a && !b) || (!a && b).

Err... what you want is just: a != b

That's right. I somehow overlooked that. :) /Oskar
Mar 05 2006
parent Miles <_______ _______.____> writes:
Oskar Linde wrote:
 I apologize. I didn't notice that KNode put a single group
 followup-to-header instead of keeping cross-posting (I assume this is what
 you are referring to). I will remove the follow-up from this post, but I
 think KNodes behavior is correct. It is stupid to keep cross-posting this
 discussion on the two probably most read D newsgroups.

It is a bug, indeed. See https://bugs.kde.org/show_bug.cgi?id=68732 . This "misfeature" causes much more confusion than solution, and it forces something that is not natural. KNode sets a followup-to header to groups that you are not subscribed. Most of time, it also sets stupid followups (like now, this discussion is much more relevant to D thant to D.announce, and your KNode set it to D.announce). To finish, if people replying to your message don't notice, they end up posting to newsgroups they are perhaps not even subscribed, and will never see their own posts. Even if they notice, it is a pain to manually fix the destination. This behavior of KNode is more annoying than anything, and it makes it looks like cross-posts are something evil, while in fact they are useful and there is a perfect reason for them. Well... this is getting way off-topic...
Mar 05 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
news:du002m$2pnp$1 digitaldaemon.com...
 The code could have been while(5). Do you really think 5 is true?

The while expression must be convertible to a boolean, it needn't be a boolean. I'm perfectly comfortable with the !=0 nature of the test, and not just because I've been doing it for 25 years. It was comfortable right out of the gate (and I came to C from Pascal, and never wrote another line of Pascal after my first encounter with C).
 The problem in all these bool wars so far is I never saw an argument that 
 would be against true booleans (while(BooleanExpression) and all that...).
 The arguments like:
 while(true) is much much bigger than while(1) or
 while(a)    is much smaller and more understandable than while(a>0)
 //hm while(a) is actually while(a!=0) but did I really mean a>0?)
 and like that don't really count.

 Adding true booleans makes no code break, only adds compiler errors that 
 make  a coder think more about what he is doing and require awfull changes 
 from if(b) to if(b!=0) and stop him from doing things like adding two 
 bools or adding an int to a bool.

Like I said, I never looked back with nostalgia upon Pascal after using C <g>. I know many people think the wordier versions are more readable. I don't. I'm also very reluctant to abandon things that may have contributed to C being wildly popular and burying Pascal in an unmarked grave out in the desert.
 I still wonder why do you think that many modern and much used languages 
 implement real boolean types and are very proud of that? Does the 
 behaviour of D really fix C/C++ bool isues? Will those seeking a real bool 
 people not say <g> and write alias/typedef int boolean, or something else?

 I think those languages have bools because they realize bool is *not* an 
 int but a mathematical concept.

Bool's particular behavior just doesn't have the leverage to make much of any difference in real programs. On_scope is far more interesting, because for a certain class of programming problems it can have a dramatic effect on improving them.
Feb 28 2006
next sibling parent "Lionello Lunesu" <lio remove.lunesu.com> writes:
 Bool's particular behavior just doesn't have the leverage to make much of 
 any difference in real programs. On_scope is far more interesting, because 
 for a certain class of programming problems it can have a dramatic effect 
 on improving them.

That's actually the best point so far. I agree. L.
Feb 28 2006
prev sibling parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Walter Bright wrote:
 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
 The problem in all these bool wars so far is I never saw an argument that 
 would be against true booleans (while(BooleanExpression) and all that...).
 The arguments like:
 while(true) is much much bigger than while(1) or
 while(a)    is much smaller and more understandable than while(a>0)
 //hm while(a) is actually while(a!=0) but did I really mean a>0?)
 and like that don't really count.

 Adding true booleans makes no code break, only adds compiler errors that 
 make  a coder think more about what he is doing and require awfull changes 
 from if(b) to if(b!=0) and stop him from doing things like adding two 
 bools or adding an int to a bool.

Like I said, I never looked back with nostalgia upon Pascal after using C <g>. I know many people think the wordier versions are more readable. I don't. I'm also very reluctant to abandon things that may have contributed to C being wildly popular and burying Pascal in an unmarked grave out in the desert.

Thinking about that (the Pascal verbosity), I find that in most cases I agree that wordier versions are less readable, however, that is only *usually*, not in all situations. It really has to be considered on an individual case, not on a general basis. For instance, I abhor the BEGIN/END construct, so much that I immediately distrust any language with it (yes Ruby, that means you..). I also find stuff like VAR and THEN annoying, but in the case of '1' vs 'true', I prefer 'true'. We can't go completely against the way of wordiness, because that would be the road to obfuscation. Do not generalize, look at each case appropriately. And harmony is the key. -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Feb 28 2006
prev sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:
 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
 news:dttebh$2kqq$1 digitaldaemon.com...
 
Ever seen this:

while(1)

I sure did, and it scares the hell out of me :)

Why? This is a practice I got into with C/C++, and I did it because 1 cannot be redefined by the preprocessor into something goofy. I.e., I *knew* what it was without having to go spelunking through header files.

One more thing. I heared from a Ruby user that in Ruby 0 means true. To that user while(1) is pefectly obvious it is a block of code executed exactly once. No problems in understanding that for a Ruby user. But to me 1 isn't true, and isn't false. It is an implementation detail that should be hidden from users. As I said in another thread: programming language constructs should have a meaning when translated to a human language. What would: "if 75 then some people dont like type safety" mean? To me and a lot more people it means nothing.
Feb 27 2006
next sibling parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Ivan Senji wrote:
 One more thing. I heared from a Ruby user that in Ruby 0 means true.

To clarify, since that makes it sound a bit too much like "...and 1 means false": in Ruby the only two things that are false are, of course, false itself, and nil, which is similar to D's null. 0, like all other numbers, is true.
Feb 27 2006
parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Deewiant wrote:
 Ivan Senji wrote:
 
One more thing. I heared from a Ruby user that in Ruby 0 means true.

To clarify, since that makes it sound a bit too much like "...and 1 means false": in Ruby the only two things that are false are, of course, false itself, and nil, which is similar to D's null. 0, like all other numbers, is true.

Thanks for the clarification. It is really interesting how Ruby takes a completly different approach. Not that I agree with it. Strange and arbitrary decision IMO to make all numbers true. Why not make all numbers false?
Feb 27 2006
parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Ivan Senji wrote:
 Deewiant wrote:
 Ivan Senji wrote:

 One more thing. I heared from a Ruby user that in Ruby 0 means true.

To clarify, since that makes it sound a bit too much like "...and 1 means false": in Ruby the only two things that are false are, of course, false itself, and nil, which is similar to D's null. 0, like all other numbers, is true.

Thanks for the clarification. It is really interesting how Ruby takes a completly different approach. Not that I agree with it. Strange and arbitrary decision IMO to make all numbers true. Why not make all numbers false?

Probably because of Ruby's TIMTOWTDI approach - There Is More Than One Way To Do It. Thus, it tries to cater to programmers of all languages - including C, and so if you liked to write "while (1)" before you can still write "while (1)". You can also write "loop do", "for (;;)", "while (true)", and probably do the same thing in at least a dozen other ways. Point being that Ruby has no reason - and it might even be against its idioms - to take so clearly a deviant approach to true and false as to declare numbers false, when in most languages people nowadays use everything apart from 0 is true. Why, then, 0 is true, I cannot say; probably because all other numbers are true, and 0 has no need to be an exception. It might be true in other languages because they are strongly typed (or at least somewhat strongly - C isn't that strongly typed, and even in D pointer arithmetic can do quite a bit to break the type system, AFAIK), and a "false" value is very handy for a function that returns an integer. In Ruby, you can just return false or nil, whichever is appropriate, on error, even if the method in question normally returns an integer.
Feb 27 2006
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Ivan Senji wrote:

 ...
 One more thing. I heared from a Ruby user that in Ruby 0 means true.
 To that user while(1) is pefectly obvious it is a block of code executed
 exactly once. No problems in understanding that for a Ruby user.
 ...

Yes. IIRC in Ruby everything except Null and False is handled as if it were true. There's some justification that I can't remember...probably "That's the way Perl does it", but that's just a guess. OTOH, Ruby doesn't even TRY to be type safe. I like Ruby a lot, but that's not the way I think things should be handled. And I'm all in favor of Boolean being a type of size 1 that, if it implements + and *, implements them as "or" and "and"...and NEVER automatically converts to or from any arithmetic form. That seems to me to be much more reasonable. (Yes, C didn't do it that way. C didn't even HAVE a boolean type. [Well, the first C compilers I used didn't...bool was implemented via a macro substitution for int.] So I don't find that a very powerful argument for what D should do.) Still, no language is perfect, and as warts go, this is a small one.
Feb 27 2006
parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Charles Hixson wrote:
 Ivan Senji wrote:
 
 
...
One more thing. I heared from a Ruby user that in Ruby 0 means true.
To that user while(1) is pefectly obvious it is a block of code executed
exactly once. No problems in understanding that for a Ruby user.
...

Yes. IIRC in Ruby everything except Null and False is handled as if it were true. There's some justification that I can't remember...probably "That's the way Perl does it", but that's just a guess. OTOH, Ruby doesn't even TRY to be type safe. I like Ruby a lot, but that's not the way I think things should be handled. And I'm all in favor of Boolean being a type of size 1 that, if it implements + and *, implements them as "or" and "and"...and NEVER automatically converts to or from any arithmetic form.

Another Bool believer ;)
 That seems to me to be much more reasonable.  (Yes, C
 didn't do it that way.  C didn't even HAVE a boolean type.  [Well, the
 first C compilers I used didn't...bool was implemented via a macro
 substitution for int.]  So I don't find that a very powerful argument for
 what D should do.)

I agree.
 
 Still, no language is perfect, and as warts go, this is a small one.
 

No language is perfect, but I don't think it is souch a small problem in a language claiming to be a modern language.
Feb 28 2006
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Mon, 27 Feb 2006 01:29:07 +0200, Georg Wrede wrote:

 
 Ok, I'll give an example of that right after you give an example of why 
 and where this is needed/good/(not extremly bad):
 
   bool a, b, c;
   a = true;
   b = true;
   c = true;
 
   a = b+c; // true + true is what?

That's why we do want to have booleans. The whole point of having booleans is to not do that by mistake.

But D currently allows this to happen. It's boolean implementation is broken.
   if(5) //if 5 what? what does that mean (except nothing)?

Ever seen this: while(1) written in source code? Or this: c = getCharacter(inf); if (c) { /* whatever */ } Oh, by the way, just checked how many times 'while(1)' appears in src/phobos/std: grep "while *( *1 *)" *.d |wc answer: 16 times.

Aren't you reading my posts anymore ;-) while(1) is shorthand for while (1 != 0) and c = getCharacter(inf); if (c) { /* whatever */ } is shorthand for c = getCharacter(inf); if (c != 0) { /* whatever */ } -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 27/02/2006 12:00:30 PM
Feb 26 2006
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 27 Feb 2006 00:17:12 +0200, Georg Wrede wrote:

 Derek Parnell wrote:
 On Mon, 27 Feb 2006 06:05:13 +1100, Georg Wrede <georg nospam.org> wrote:

 We've all had our fights with C, C++, and other related languages. 
 But  honestly, how many of us can confess to having problems with 
 logical  values?

Me.
 And if someone here has such problems, I suggest switching to VB.

I am also a VB coder and I'm not a language bigot.

Oh. I'm sorry. I'll try not to mention VB in the future.

That's okay, you don't have to be embarrassed amongst friends. There are still a lot of people that regard BASIC, and VB in particular, as 'not real programming languages'.
 ---
 
 I think we've gotten it backwards here, so let's turn the table:
 
 Can you give some example code and use cases where we absolutely need 
 your kind of booleans?

Imagine that someone wrote a library function that reads a text file in and returns the number of lines read in. You know that a file with less than 3 lines is invalid, so you write ... int cnt = read_text(filename); if (cnt < 3) throw new Exception(...); However, later on the library is updated and now returns a boolean: true if successful, and false otherwise. Your programs will still compile but it shouldn't. And it will always fail at run time even if the file read in contained three or more lines. However, if we had a true boolean semantics, the compiler would display an error instead of you getting a run time error. To point is that a language that implemented boolean semantics could help eliminate a set of coding errors that D's 'bool' will not catch. In the same way that 'real' and 'int' are used to catch such errors. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 27/02/2006 9:58:09 AM
Feb 26 2006
parent Georg Wrede <georg nospam.org> writes:
Derek Parnell wrote:
 On Mon, 27 Feb 2006 00:17:12 +0200, Georg Wrede wrote:
 Derek Parnell wrote:
 Georg Wrede <georg nospam.org> wrote:



 We've all had our fights with C, C++, and other related languages. 
 But  honestly, how many of us can confess to having problems with 
 logical  values?

Me.
 And if someone here has such problems, I suggest switching to VB.

I am also a VB coder and I'm not a language bigot.

Oh. I'm sorry. I'll try not to mention VB in the future.

That's okay, you don't have to be embarrassed amongst friends. There are still a lot of people that regard BASIC, and VB in particular, as 'not real programming languages'.

Oh man, "still"! Derek, you're killing me! :-) BTW, did you too notice that the way this thread has been going the last couple of hours and all posters here now, one'd think its Friday Night!
Feb 26 2006
prev sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Georg Wrede wrote:
 Well, then we could skip the logical operators, right? No more && or ||. 
 Since all booleans would be strictly 0 or 1, they'd become obsolete.

What? Did you here this correctly? You are saying remove logical operators (the operators working on booleans in theory)? How would they become obsolete? They would get a meaning with true booleans. I must say that i don't have a clue what is the result of 17 && 301? But I do know that true && true == true.
 
 And if booleans have to only be 0 or 1, then a whole lot of unnecessary 
 conversions would be happening all over the place. Forget D speed.

No they don't. They can be anything they wan't to be. But the compiler should hide that from me and convince me I live in a world of Boolean algebra.
 
 Also, D is supposed to be a _systems_language_ for chrissake! Any kernel 
 writing would then have to forgo booleans totally.

No.
 
 I'm all for features in D that enhance productivity, but deliberately 
 dumbing down the language is getting a bit too far.

Making it typesafe and consisten with mathematical definitions of bools is dumbing? I somehow don't see why?
 
 ---
 
 We've all had our fights with C, C++, and other related languages. But 
 honestly, how many of us can confess to having problems with logical 
 values?

I have problems with bools. I can't sleep at night if they are ints ;)
Feb 26 2006
parent reply Georg Wrede <georg nospam.org> writes:
This is getting hilarious...


Ivan Senji wrote:
 Georg Wrede wrote:
 
 Well, then we could skip the logical operators, right? No more && or 
 ||. Since all booleans would be strictly 0 or 1, they'd become obsolete.

What? Did you here this correctly? You are saying remove logical operators (the operators working on booleans in theory)? How would they become obsolete? They would get a meaning with true booleans.

If Booleans are only 0 or 1, then & and | suffice. && and || become useless, and we can delete them from the compiler sources. Not to mention the lots of ink we could save!
 I must say that i don't have a clue what is the result of 17 && 301?

I have no problem believing that's true.
 And if booleans have to only be 0 or 1, then a whole lot of 
 unnecessary conversions would be happening all over the place. Forget 
 D speed.

No they don't. They can be anything they wan't to be. But the compiler should hide that from me and convince me I live in a world of Boolean algebra.

Since I've just promised not to recommend a certain language from Redmond, maybe I could recommend some substance?
 We've all had our fights with C, C++, and other related languages. But 
 honestly, how many of us can confess to having problems with logical 
 values?

I have problems with bools. I can't sleep at night if they are ints ;)

Oh. Maybe then a prescription substance?
Feb 26 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Georg Wrede wrote:
 This is getting hilarious...

Really? I'm glad that this entertains you?
 
 
 Ivan Senji wrote:
 
 Georg Wrede wrote:

 Well, then we could skip the logical operators, right? No more && or 
 ||. Since all booleans would be strictly 0 or 1, they'd become obsolete.

What? Did you here this correctly? You are saying remove logical operators (the operators working on booleans in theory)? How would they become obsolete? They would get a meaning with true booleans.

If Booleans are only 0 or 1, then & and | suffice. && and || become useless, and we can delete them from the compiler sources.

That is one part I didn't understand. Why would booleans have to be 0 or 1? (or are you kidding, I'm too tired to be sure). & is totally different from &&, & compares bits one by one, and && is equivalent to * in Boolean algebra, two different concepts mustn't be combined like that.
 
 Not to mention the lots of ink we could save!

That's true.
 
 I must say that i don't have a clue what is the result of 17 && 301?

I have no problem believing that's true.
 And if booleans have to only be 0 or 1, then a whole lot of 
 unnecessary conversions would be happening all over the place. Forget 
 D speed.

No they don't. They can be anything they wan't to be. But the compiler should hide that from me and convince me I live in a world of Boolean algebra.

Since I've just promised not to recommend a certain language from Redmond, maybe I could recommend some substance?

Sure, maybe C#? C# got bools right too.
 
 We've all had our fights with C, C++, and other related languages. 
 But honestly, how many of us can confess to having problems with 
 logical values?

I have problems with bools. I can't sleep at night if they are ints ;)

Oh. Maybe then a prescription substance?

No thanks :)
Feb 26 2006
parent reply Georg Wrede <georg nospam.org> writes:
Ivan Senji wrote:
 Georg Wrede wrote:

 That is one part I didn't understand. Why would booleans have to be 0 or 
 1? (or are you kidding, I'm too tired to be sure).

Since anything stored on a computer is representable with numbers, then we could of course have true be 27 and false be 41. But is there any profit in it, compared to 0 and 1?
Feb 26 2006
parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Georg Wrede wrote:
 Ivan Senji wrote:
 
 Georg Wrede wrote:

 That is one part I didn't understand. Why would booleans have to be 0 
 or 1? (or are you kidding, I'm too tired to be sure).

Since anything stored on a computer is representable with numbers, then we could of course have true be 27 and false be 41.

Starting to like this proposal but I would prefer true to be 42 (being the answer to the universal question of everything)
 
 But is there any profit in it, compared to 0 and 1?

Only the above.
Feb 26 2006
parent BCS <BCS_member pathlink.com> writes:
In article <dttiq1$2q5g$1 digitaldaemon.com>, Ivan Senji says...
Georg Wrede wrote:
 Ivan Senji wrote:
 
 Since anything stored on a computer is representable with numbers, then 
 we could of course have true be 27 and false be 41.

Starting to like this proposal but I would prefer true to be 42 (being the answer to the universal question of everything)

Ouch! And false must then be 54. (6*9) :P
Feb 26 2006
prev sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Georg Wrede wrote:
 
 
 This is getting hilarious...
 
 
 Ivan Senji wrote:
 Georg Wrede wrote:

 Well, then we could skip the logical operators, right? No more && or 
 ||. Since all booleans would be strictly 0 or 1, they'd become obsolete.

What? Did you here this correctly? You are saying remove logical operators (the operators working on booleans in theory)? How would they become obsolete? They would get a meaning with true booleans.

If Booleans are only 0 or 1, then & and | suffice. && and || become useless, and we can delete them from the compiler sources. Not to mention the lots of ink we could save!
 I must say that i don't have a clue what is the result of 17 && 301?

I have no problem believing that's true.
 And if booleans have to only be 0 or 1, then a whole lot of 
 unnecessary conversions would be happening all over the place. Forget 
 D speed.

No they don't. They can be anything they wan't to be. But the compiler should hide that from me and convince me I live in a world of Boolean algebra.

Since I've just promised not to recommend a certain language from Redmond, maybe I could recommend some substance?
 We've all had our fights with C, C++, and other related languages. 
 But honestly, how many of us can confess to having problems with 
 logical values?

I have problems with bools. I can't sleep at night if they are ints ;)

Oh. Maybe then a prescription substance?

Georg, reading your posts on this NG has given me great insight into the breadth of your knowledge and the depth of your wisdom. Your sarcasm is always poigniant and appropo. Your jibes at your fellow NG's always in good taste. And your blind cheerleading and bandwagoning the height of prudence and solid judgement. Keep up the good work!
Feb 26 2006
parent reply Georg Wrede <georg nospam.org> writes:
Kyle Furlong wrote:
 Georg Wrede wrote:
 
 This is getting hilarious...


 Georg, reading your posts on this NG has given me great insight into the 
 breadth of your knowledge and the depth of your wisdom. Your sarcasm is 
 always poigniant and appropo. Your jibes at your fellow NG's always in 
 good taste. And your blind cheerleading and bandwagoning the height of 
 prudence and solid judgement. Keep up the good work!

Thanks! Which reminds me, better go to bed before it gets too hilarious... georg PS, haven't had this much fun for a long time. I hope everyone else enjoyed it too!
Feb 26 2006
next sibling parent Tom <Tom_member pathlink.com> writes:
In article <44025193.2060501 nospam.org>, Georg Wrede says...
Kyle Furlong wrote:
 Georg Wrede wrote:
 
 This is getting hilarious...


 Georg, reading your posts on this NG has given me great insight into the 
 breadth of your knowledge and the depth of your wisdom. Your sarcasm is 
 always poigniant and appropo. Your jibes at your fellow NG's always in 
 good taste. And your blind cheerleading and bandwagoning the height of 
 prudence and solid judgement. Keep up the good work!

Thanks! Which reminds me, better go to bed before it gets too hilarious...

Me too, have to work and study tomorrow, shouldn't have "wasted" so much time having fun with you guys.
georg

PS, haven't had this much fun for a long time. I hope everyone else 
enjoyed it too!

I almost can say that I feel appreciation for all people involved (it's unavoidable as you all seem to be nice guys). But remember, bool doesn't worth a bloodshed :P Tom;
Feb 26 2006
prev sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Georg Wrede wrote:
 Kyle Furlong wrote:
 
 Georg Wrede wrote:

 This is getting hilarious...


 Georg, reading your posts on this NG has given me great insight into 
 the breadth of your knowledge and the depth of your wisdom. Your 
 sarcasm is always poigniant and appropo. Your jibes at your fellow 
 NG's always in good taste. And your blind cheerleading and 
 bandwagoning the height of prudence and solid judgement. Keep up the 
 good work!

Thanks! Which reminds me, better go to bed before it gets too hilarious... georg PS, haven't had this much fun for a long time. I hope everyone else enjoyed it too!

Me too. NG chating is a funny thing.
Feb 26 2006
prev sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Mon, 27 Feb 2006 00:02:08 +1100, Georg Wrede <georg nospam.org> wrote:

 Derek Parnell wrote:
 Walter is still living in the C/C++ past with this concept, which is   
 strange seeing he has implemented so many progressive concepts in D.   
 Boolean as an integer is just retro.

So am I.

Apparently so.
 Booleans have to be int.

Why? And do you mean they have to be implemented using 'int' or are you saying that they are intrinsically integers?
 A boolean may have any "numeric" value, but if   implicitly cast to a  
 numeric type, it should return 1 or 0.

Why?
 D IS A PRACTICAL PROGRAMMING LANGUAGE.

Which means what, exactly? For example, does the term 'practical' also embrace the concept of 'cost-effective to maintain'?
 Forcing booleans to be 1/0 all the way is just academic, purist,  
 impractical bigotry. About as smart as having the bit type.

No one is saying that booleans must be forced to be 1/0? Why did you think that this was what I was saying?
 (Besides, if booleans, as some say here, are _only_ abstract concepts,  
 then we might as well decide to have 0 mean true and 1 mean false.

Exactly! The implementation is not the concept. Of course, this would not be a very efficient implementation but it is a possiblity.
 Heh, there's only one truth but millions of lies! But we live in a world  
 with other people. And computers.)

Did you just say that there is one 'zero' but millions of 'ones'?
 Now, specifying 0 to mean false and everything else to mean not-false,  
 we go along with the hardware, the computer industry, half a century of  
 programming PRACTICE, and make life less difficult for anybody with a  
 professional programming background before moving to D.

And that's why it is a more efficient implementation. I agree that this is how booleans will probably be implemented. But there are other sematics that go with numbers that do not belong in the domain of booleans. -- Derek Parnell Melbourne, Australia
Feb 26 2006
parent reply James Dunne <james.jdunne gmail.com> writes:
Derek Parnell wrote:
 On Mon, 27 Feb 2006 00:02:08 +1100, Georg Wrede <georg nospam.org> wrote:
 
 Derek Parnell wrote:

 Walter is still living in the C/C++ past with this concept, which 
 is   strange seeing he has implemented so many progressive concepts 
 in D.   Boolean as an integer is just retro.

So am I.

Apparently so.
 Booleans have to be int.

Why? And do you mean they have to be implemented using 'int' or are you saying that they are intrinsically integers?
 A boolean may have any "numeric" value, but if   implicitly cast to a  
 numeric type, it should return 1 or 0.

Why?
 D IS A PRACTICAL PROGRAMMING LANGUAGE.

Which means what, exactly? For example, does the term 'practical' also embrace the concept of 'cost-effective to maintain'?
 Forcing booleans to be 1/0 all the way is just academic, purist,  
 impractical bigotry. About as smart as having the bit type.

No one is saying that booleans must be forced to be 1/0? Why did you think that this was what I was saying?
 (Besides, if booleans, as some say here, are _only_ abstract 
 concepts,  then we might as well decide to have 0 mean true and 1 mean 
 false.

Exactly! The implementation is not the concept. Of course, this would not be a very efficient implementation but it is a possiblity.
 Heh, there's only one truth but millions of lies! But we live in a 
 world  with other people. And computers.)

Did you just say that there is one 'zero' but millions of 'ones'?

I actually laughed out loud at that. Good catch man. This is why I love this NG. :)
 Now, specifying 0 to mean false and everything else to mean 
 not-false,  we go along with the hardware, the computer industry, half 
 a century of  programming PRACTICE, and make life less difficult for 
 anybody with a  professional programming background before moving to D.

And that's why it is a more efficient implementation. I agree that this is how booleans will probably be implemented. But there are other sematics that go with numbers that do not belong in the domain of booleans.

-- Regards, James Dunne
Feb 26 2006
parent Georg Wrede <georg nospam.org> writes:
James Dunne wrote:
 Derek Parnell wrote:
 
 On Mon, 27 Feb 2006 00:02:08 +1100, Georg Wrede <georg nospam.org> wrote:

 Derek Parnell wrote:

 Walter is still living in the C/C++ past with this concept, which 
 is   strange seeing he has implemented so many progressive concepts 
 in D.   Boolean as an integer is just retro.

So am I.

Apparently so.
 Booleans have to be int.

Why? And do you mean they have to be implemented using 'int' or are you saying that they are intrinsically integers?
 A boolean may have any "numeric" value, but if   implicitly cast to 
 a  numeric type, it should return 1 or 0.

Why?
 D IS A PRACTICAL PROGRAMMING LANGUAGE.

Which means what, exactly? For example, does the term 'practical' also embrace the concept of 'cost-effective to maintain'?
 Forcing booleans to be 1/0 all the way is just academic, purist,  
 impractical bigotry. About as smart as having the bit type.

No one is saying that booleans must be forced to be 1/0? Why did you think that this was what I was saying?
 (Besides, if booleans, as some say here, are _only_ abstract 
 concepts,  then we might as well decide to have 0 mean true and 1 
 mean false.

Exactly! The implementation is not the concept. Of course, this would not be a very efficient implementation but it is a possiblity.
 Heh, there's only one truth but millions of lies! But we live in a 
 world  with other people. And computers.)

Did you just say that there is one 'zero' but millions of 'ones'?

I actually laughed out loud at that. Good catch man. This is why I love this NG. :)

So did I. At myself. Of course, I meant to write "decide to have 0 mean true and anything else mean false -- only one truth but millions of lies".
 Now, specifying 0 to mean false and everything else to mean 
 not-false,  we go along with the hardware, the computer industry, 
 half a century of  programming PRACTICE, and make life less difficult 
 for anybody with a  professional programming background before moving 
 to D.

And that's why it is a more efficient implementation. I agree that this is how booleans will probably be implemented. But there are other sematics that go with numbers that do not belong in the domain of booleans.


Feb 26 2006
prev sibling parent reply Wang Zhen <nehzgnaw gmail.com> writes:
Derek Parnell wrote:
 On Sun, 26 Feb 2006 17:29:03 +1100, Wang Zhen <nehzgnaw gmail.com> wrote:
 
 Derek Parnell wrote:

 On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright   
 <newshound digitalmars.com> wrote:

 Lots of new stuff, I added new threads for them in the digitalmars.D
 newsgroup.

implicit conversion to int. That is just a cheap cop out for lazy coding, IMNSHO.

Pardon my ignorance,

That's okay.
 but why does D need a primitive type for booleans in the first place?  
 What's wrong with "alias ubyte bool;" or "alias int bool;"?

The short answer is that booleans are not numbers. They represent truth and falsehood.
 Can't we simply treat zero as false and non-zero as true as we C  
 programmers always do?

*We* are not C programmers ;-) *We* have grown up from that baby-talk ;-) Zero is frequently used to implement the concept of falsehood and likewise non-zero for truth, however the semantics of integers is not the same as the semantics of booleans. But because many C programers are just *so* used to thinking this way they have become to believe that zero *is* falsehood rather than just a number chosen to implement the concept.

32-bit int is frequently used to implement the concept of integers, but they are semantically different. So what? Be a language purist and refuse to call int an integer until programmers can store arbitrary integers without having to worry about the implementation details?
 It is quite possible for a language to implement falsehood/truth is 
 ways  other than using integers but even if they do, the compiler can 
 still  ensure that the sematics are adhered to rather than continue 
 using integer  sematics.
 
 The only thing I can see wrong with D's new boolean is that it still  
 pretends its a number. Why is this wrong? Because it can lead to coding  
 mistakes and abuse. Thus making maintenance more costly than it needed 
 to  be.

Pretending that bool is not a number can possibly lead to more confusion and misuse. Besides, many other features can also be abused in a practical language like D. Abandon them all just in case some unconscious programmer might make a mistake?
 Walter is still living in the C/C++ past with this concept, which is  
 strange seeing he has implemented so many progressive concepts in D.  
 Boolean as an integer is just retro.

I'm still not convinced why oldschool integer bools are inferior to newschool bools which may be abused by pointer tricks anyway.
Feb 26 2006
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Wang Zhen wrote:
 Derek Parnell wrote:
 On Sun, 26 Feb 2006 17:29:03 +1100, Wang Zhen <nehzgnaw gmail.com> wrote:

 Derek Parnell wrote:

 On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright   
 <newshound digitalmars.com> wrote:

 Lots of new stuff, I added new threads for them in the digitalmars.D
 newsgroup.

implicit conversion to int. That is just a cheap cop out for lazy coding, IMNSHO.

Pardon my ignorance,

That's okay.
 but why does D need a primitive type for booleans in the first 
 place?  What's wrong with "alias ubyte bool;" or "alias int bool;"?

The short answer is that booleans are not numbers. They represent truth and falsehood.
 Can't we simply treat zero as false and non-zero as true as we C  
 programmers always do?

*We* are not C programmers ;-) *We* have grown up from that baby-talk ;-) Zero is frequently used to implement the concept of falsehood and likewise non-zero for truth, however the semantics of integers is not the same as the semantics of booleans. But because many C programers are just *so* used to thinking this way they have become to believe that zero *is* falsehood rather than just a number chosen to implement the concept.

32-bit int is frequently used to implement the concept of integers, but they are semantically different. So what? Be a language purist and refuse to call int an integer until programmers can store arbitrary integers without having to worry about the implementation details?
 It is quite possible for a language to implement falsehood/truth is 
 ways  other than using integers but even if they do, the compiler can 
 still  ensure that the sematics are adhered to rather than continue 
 using integer  sematics.

 The only thing I can see wrong with D's new boolean is that it still  
 pretends its a number. Why is this wrong? Because it can lead to 
 coding  mistakes and abuse. Thus making maintenance more costly than 
 it needed to  be.

Pretending that bool is not a number can possibly lead to more confusion and misuse. Besides, many other features can also be abused in a practical language like D. Abandon them all just in case some unconscious programmer might make a mistake?
 Walter is still living in the C/C++ past with this concept, which is  
 strange seeing he has implemented so many progressive concepts in D.  
 Boolean as an integer is just retro.

I'm still not convinced why oldschool integer bools are inferior to newschool bools which may be abused by pointer tricks anyway.

The point has to do with the type system. Yes, you can always hack any type by using pointer tricks. So what is the point of having a type system in the first place? Having all booleans as integers is just wrong, they have different constraints, are different kinds of entities, even if they are backed by the same kind of storage.
Feb 26 2006
prev sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Mon, 27 Feb 2006 02:43:56 +1100, Wang Zhen <nehzgnaw gmail.com> wrote:

 Derek Parnell wrote:
 On Sun, 26 Feb 2006 17:29:03 +1100, Wang Zhen <nehzgnaw gmail.com>  
 wrote:

 Derek Parnell wrote:

 On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright    
 <newshound digitalmars.com> wrote:

 Lots of new stuff, I added new threads for them in the digitalmars.D
 newsgroup.

implicit conversion to int. That is just a cheap cop out for lazy coding, IMNSHO.

Pardon my ignorance,

 but why does D need a primitive type for booleans in the first place?   
 What's wrong with "alias ubyte bool;" or "alias int bool;"?

truth and falsehood.
 Can't we simply treat zero as false and non-zero as true as we C   
 programmers always do?

;-) Zero is frequently used to implement the concept of falsehood and likewise non-zero for truth, however the semantics of integers is not the same as the semantics of booleans. But because many C programers are just *so* used to thinking this way they have become to believe that zero *is* falsehood rather than just a number chosen to implement the concept.

32-bit int is frequently used to implement the concept of integers, but they are semantically different.

I understood that a 32-bit int was used to implement a subset of integers, not the whole range.
 So what? Be a language purist and refuse to call int an integer until  
 programmers can store arbitrary integers without having to worry about  
 the implementation details?

An 'int' *is* an integer. But an integer is not necessarily an 'int'. I don't find this a difficult concept.
 It is quite possible for a language to implement falsehood/truth is  
 ways  other than using integers but even if they do, the compiler can  
 still  ensure that the sematics are adhered to rather than continue  
 using integer  sematics.
  The only thing I can see wrong with D's new boolean is that it still   
 pretends its a number. Why is this wrong? Because it can lead to  
 coding  mistakes and abuse. Thus making maintenance more costly than it  
 needed to  be.

Pretending that bool is not a number can possibly lead to more confusion and misuse. Besides, many other features can also be abused in a practical language like D. Abandon them all just in case some unconscious programmer might make a mistake?

Who is pretending? I'm not. A boolean is not a number. If it was, you should be able to arithmetic with it, but 'what is truth raised to the power 4?' is nonsense.
 Walter is still living in the C/C++ past with this concept, which is   
 strange seeing he has implemented so many progressive concepts in D.   
 Boolean as an integer is just retro.

I'm still not convinced why oldschool integer bools are inferior to newschool bools which may be abused by pointer tricks anyway.

Huh? I'm not getting this across very well am I :) D can use integers (32-bit ints) to implement booleans if this is efficient. I have no problem with that. However, the compiler should not allow arithmetic to be done on them, or implicit conversion of 'int' to 'bool' The compiler can detect this stuff and it is totally independant how how they are implemented. bool x; x = 8; if (x == 4) { writefln("This code says that 8 and 4 are the same"); } bool x; x = cast(bool)8; if (x == cast(bool)4) { writefln("This code says that 8, when cast to a bool, " "is the same as 4, when that is also cast to bool"); } bool x; x = true; if (x == true) { writefln("This code says 'true' and 'true' are the same."); } -- Derek Parnell Melbourne, Australia
Feb 26 2006
parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Derek Parnell wrote:
 On Mon, 27 Feb 2006 02:43:56 +1100, Wang Zhen <nehzgnaw gmail.com> wrote:
 
 Derek Parnell wrote:


 32-bit int is frequently used to implement the concept of integers, 
 but  they are semantically different.

I understood that a 32-bit int was used to implement a subset of integers, not the whole range.

And that is exactly the way I understand it, actually it *is* that way.
 
 So what? Be a language purist and refuse to call int an integer until  
 programmers can store arbitrary integers without having to worry 
 about  the implementation details?

An 'int' *is* an integer. But an integer is not necessarily an 'int'. I don't find this a difficult concept.

Very simple concept indeed.
 
 It is quite possible for a language to implement falsehood/truth is  
 ways  other than using integers but even if they do, the compiler 
 can  still  ensure that the sematics are adhered to rather than 
 continue  using integer  sematics.
  The only thing I can see wrong with D's new boolean is that it 
 still   pretends its a number. Why is this wrong? Because it can lead 
 to  coding  mistakes and abuse. Thus making maintenance more costly 
 than it  needed to  be.

Pretending that bool is not a number can possibly lead to more confusion and misuse. Besides, many other features can also be abused in a practical language like D. Abandon them all just in case some unconscious programmer might make a mistake?

Who is pretending? I'm not. A boolean is not a number. If it was, you should be able to arithmetic with it, but 'what is truth raised to the power 4?' is nonsense.

Well you might say that it is true*true*true*true == true && true && true && true == true :) But than I would expect operators + and * to behave like || and &&. :)
Feb 26 2006
prev sibling parent reply Charles <noone nowhere.com> writes:
 Can't we simply treat zero as false and non-zero as true as we C
 programmers always do?

I agree, I still don't get what the 'true bool' fuss is about . Wang Zhen wrote:
 Derek Parnell wrote:
 
 On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright  
 <newshound digitalmars.com> wrote:

 Lots of new stuff, I added new threads for them in the digitalmars.D
 newsgroup.

Well you almost got bool right <G> Everything except that it does implicit conversion to int. That is just a cheap cop out for lazy coding, IMNSHO.

Pardon my ignorance, but why does D need a primitive type for booleans in the first place? What's wrong with "alias ubyte bool;" or "alias int bool;"? Can't we simply treat zero as false and non-zero as true as we C programmers always do?
 //--------------------
 import std.stdio;

 void main()
 {
   bool a;
   bool b;
   bool c;
   bool d;
   int e;

   a = true;
   b = true;
   c = true;
   d = a + b + c;
   e = a + b + c; // In a decent implentation, this should have failed 
 to  compile
   writefln("%s %s %s %s %s", a,b,c,d,e);
   writefln("%d %d %d %d %d", a,b,c,d,e); // And this might have been 
 a  runtime error?

 }
 //-------------------


Feb 26 2006
next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Charles schrieb am 2006-02-26:
 Can't we simply treat zero as false and non-zero as true as we C
 programmers always do?

I agree, I still don't get what the 'true bool' fuss is about .

if(b==1) { ... } instead of if(b!=0) { ... } can be found in quite a lot of C code ... -----BEGIN PGP SIGNATURE----- iD8DBQFEAfkq3w+/yD4P9tIRAjjeAKC1VyqNp5rrmzTVXSuwQXPlE/kFRwCfX+Uk Dea9+c9tXcAGCxgklIpfUp0= =rQqB -----END PGP SIGNATURE-----
Feb 26 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Sun, 26 Feb 2006 18:46:10 +0000 (UTC), Thomas Kuehne  
<thomas-dloop kuehne.cn> wrote:
 Charles schrieb am 2006-02-26:
 Can't we simply treat zero as false and non-zero as true as we C
 programmers always do?

I agree, I still don't get what the 'true bool' fuss is about .

if(b==1) { ... } instead of if(b!=0) { ... } can be found in quite a lot of C code ...

So? Assuming: - 'b' is a bool - a bool can only have 2 values, 'true' and 'false' - when you convert/promote a bool to an int you get: 'true'->'1', 'false'->'0' - when you convert/promote an int to bool you get: '0'->false, '!0'->'true' Then: if(b==1) { ... } results in 'b' being converted to int, giving it the value 1, and the comparrison working correctly. Right? Regan
Feb 26 2006
next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Mon, 27 Feb 2006 07:56:10 +1100, Regan Heath <regan netwin.co.nz> wrote:

 On Sun, 26 Feb 2006 18:46:10 +0000 (UTC), Thomas Kuehne  
 <thomas-dloop kuehne.cn> wrote:
 Charles schrieb am 2006-02-26:
 Can't we simply treat zero as false and non-zero as true as we C
 programmers always do?

I agree, I still don't get what the 'true bool' fuss is about .

if(b==1) { ... } instead of if(b!=0) { ... } can be found in quite a lot of C code ...

So? Assuming: - 'b' is a bool - a bool can only have 2 values, 'true' and 'false' - when you convert/promote a bool to an int you get: 'true'->'1', 'false'->'0' - when you convert/promote an int to bool you get: '0'->false, '!0'->'true' Then: if(b==1) { ... } results in 'b' being converted to int, giving it the value 1, and the comparrison working correctly. Right?

If it implemented that way, yes. However the problem with if(b == 1) is that the reader (future maintainer) might be mislead into thinking that 'b' is an integer and may try to use it as such by mistake. It is better to inform the reader about the true nature of 'b' by writing if (b == true) in or to remove such ambiguity. -- Derek Parnell Melbourne, Australia
Feb 26 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 27 Feb 2006 08:48:11 +1100, Derek Parnell <derek psych.ward> wrote:
 On Mon, 27 Feb 2006 07:56:10 +1100, Regan Heath <regan netwin.co.nz>  
 wrote:

 On Sun, 26 Feb 2006 18:46:10 +0000 (UTC), Thomas Kuehne  
 <thomas-dloop kuehne.cn> wrote:
 Charles schrieb am 2006-02-26:
 Can't we simply treat zero as false and non-zero as true as we C
 programmers always do?

I agree, I still don't get what the 'true bool' fuss is about .

if(b==1) { ... } instead of if(b!=0) { ... } can be found in quite a lot of C code ...

So? Assuming: - 'b' is a bool - a bool can only have 2 values, 'true' and 'false' - when you convert/promote a bool to an int you get: 'true'->'1', 'false'->'0' - when you convert/promote an int to bool you get: '0'->false, '!0'->'true' Then: if(b==1) { ... } results in 'b' being converted to int, giving it the value 1, and the comparrison working correctly. Right?

If it implemented that way, yes. However the problem with if(b == 1) is that the reader (future maintainer) might be mislead into thinking that 'b' is an integer and may try to use it as such by mistake. It is better to inform the reader about the true nature of 'b' by writing if (b == true) in or to remove such ambiguity.

Sure, but the example was old C code, presumably copied into a D source file and used. Or perhaps a C programmer not used to having bool using '1' for true. I was just pointing out that it was likely to work, not that it was as clear as it could be. Regan
Feb 26 2006
parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Regan Heath wrote:
 On Mon, 27 Feb 2006 08:48:11 +1100, Derek Parnell <derek psych.ward> wrote:
 
 On Mon, 27 Feb 2006 07:56:10 +1100, Regan Heath <regan netwin.co.nz>  
 wrote:

 On Sun, 26 Feb 2006 18:46:10 +0000 (UTC), Thomas Kuehne  
 <thomas-dloop kuehne.cn> wrote:

 Charles schrieb am 2006-02-26:

 Can't we simply treat zero as false and non-zero as true as we C
 programmers always do?

I agree, I still don't get what the 'true bool' fuss is about .

if(b==1) { ... } instead of if(b!=0) { ... } can be found in quite a lot of C code ...

So? Assuming: - 'b' is a bool - a bool can only have 2 values, 'true' and 'false' - when you convert/promote a bool to an int you get: 'true'->'1', 'false'->'0' - when you convert/promote an int to bool you get: '0'->false, '!0'->'true' Then: if(b==1) { ... } results in 'b' being converted to int, giving it the value 1, and the comparrison working correctly. Right?

If it implemented that way, yes. However the problem with if(b == 1) is that the reader (future maintainer) might be mislead into thinking that 'b' is an integer and may try to use it as such by mistake. It is better to inform the reader about the true nature of 'b' by writing if (b == true) in or to remove such ambiguity.

Sure, but the example was old C code, presumably copied into a D source file and used. Or perhaps a C programmer not used to having bool using '1' for true. I was just pointing out that it was likely to work, not that it was as clear as it could be.

I usually want my code not only to likely work. That is just not enough. What if someone writes D compiler for a strange CPU on which parity instructions are faster than comparing to 0 or 1, then we could have "true" == more zeros, "false" == more ones. Or there could be any other imaginable implementation of bools and each and every one will break on code like if(b==1), if(b==0), while(b), if(3)...
Feb 26 2006
parent "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 27 Feb 2006 00:32:25 +0100, Ivan Senji  
<ivan.senji_REMOVE_ _THIS__gmail.com> wrote:
 Regan Heath wrote:
 On Mon, 27 Feb 2006 08:48:11 +1100, Derek Parnell <derek psych.ward>  
 wrote:

 On Mon, 27 Feb 2006 07:56:10 +1100, Regan Heath <regan netwin.co.nz>   
 wrote:

 On Sun, 26 Feb 2006 18:46:10 +0000 (UTC), Thomas Kuehne   
 <thomas-dloop kuehne.cn> wrote:

 Charles schrieb am 2006-02-26:

 Can't we simply treat zero as false and non-zero as true as we C
 programmers always do?

I agree, I still don't get what the 'true bool' fuss is about .

if(b==1) { ... } instead of if(b!=0) { ... } can be found in quite a lot of C code ...

So? Assuming: - 'b' is a bool - a bool can only have 2 values, 'true' and 'false' - when you convert/promote a bool to an int you get: 'true'->'1', 'false'->'0' - when you convert/promote an int to bool you get: '0'->false, '!0'->'true' Then: if(b==1) { ... } results in 'b' being converted to int, giving it the value 1, and the comparrison working correctly. Right?

If it implemented that way, yes. However the problem with if(b == 1) is that the reader (future maintainer) might be mislead into thinking that 'b' is an integer and may try to use it as such by mistake. It is better to inform the reader about the true nature of 'b' by writing if (b == true) in or to remove such ambiguity.

source file and used. Or perhaps a C programmer not used to having bool using '1' for true. I was just pointing out that it was likely to work, not that it was as clear as it could be.

I usually want my code not only to likely work. That is just not enough.

By "likely" I actually meant it "will definately" work provided it is implemented in the way in which it is "likely" to be implemented. In other words, if it's done how I think it will be done, it "will" work fine.
 What if someone writes D compiler for a strange CPU on which parity  
 instructions are faster than comparing to 0 or 1, then we could have  
 "true" == more zeros, "false" == more ones.

 Or there could be any other imaginable implementation of bools and each  
 and every one will break on code like if(b==1), if(b==0), while(b),  
 if(3)...

All that is "possible" if not "likely". Regan
Feb 26 2006
prev sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Regan Heath schrieb am 2006-02-26:
 On Sun, 26 Feb 2006 18:46:10 +0000 (UTC), Thomas Kuehne  
<thomas-dloop kuehne.cn> wrote:
 Charles schrieb am 2006-02-26:
 Can't we simply treat zero as false and non-zero as true as we C
 programmers always do?

I agree, I still don't get what the 'true bool' fuss is about .

if(b==1) { ... } instead of if(b!=0) { ... } can be found in quite a lot of C code ...

So? Assuming: - 'b' is a bool - a bool can only have 2 values, 'true' and 'false' - when you convert/promote a bool to an int you get: 'true'->'1', 'false'->'0' - when you convert/promote an int to bool you get: '0'->false, '!0'->'true' Then: if(b==1) { ... } results in 'b' being converted to int, giving it the value 1, and the comparrison working correctly. Right?

# import std.stdio; # # int main(){ # int i = 3; # bool a = true; # bool b = *(cast(bool*)cast(void*) &i); # # writefln("a: %s", a); # writefln("b: %s", b); # writefln("int: %s", cast(int)b); // line 9 # writefln("a+b: %s", a+b); // line 10 # # return 0; # } I know, nobody writes code like that ... surprise: true -> 3 // line 9 true + true -> 4 // line 10
   - when you convert/promote a bool to an int you get: 'true'->'1',  
 'false'->'0'

The problem is: that assumtion isn't easily enforcable if bool is treated as an integer type. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFEAjK+3w+/yD4P9tIRAoFmAJ4lNdg1i5/SbYNKvN+21jiF+L4wiACgusY4 JZugXrusKOTK629hFhxmR9A= =oxIq -----END PGP SIGNATURE-----
Feb 26 2006
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Sun, 26 Feb 2006 22:03:20 +0000 (UTC), Thomas Kuehne  
<thomas-dloop kuehne.cn> wrote:
   - when you convert/promote a bool to an int you get: 'true'->'1',
 'false'->'0'

The problem is: that assumtion isn't easily enforcable if bool is treated as an integer type.

I'm no assembler expert but isn't there a single instruction for comparing to 0? Can't you therefore convert to bool with that, or it's inverse? Regan
Feb 26 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Thomas Kuehne" <thomas-dloop kuehne.cn> wrote in message 
news:0fo9d3-mb8.ln1 birke.kuehne.cn...
 # import std.stdio;
 #
 # int main(){
 # int i = 3;
 # bool a = true;

The next line goes around the type system completely, invalidates any invariants on the contents, and so any "surprising" results should be unsurprising:
 # bool b = *(cast(bool*)cast(void*) &i);

 #
 # writefln("a: %s", a);
 # writefln("b: %s", b);
 # writefln("int: %s", cast(int)b); // line 9
 # writefln("a+b: %s", a+b); // line 10
 #
 # return 0;
 # }

 I know, nobody writes code like that ...

 surprise:
 true -> 3 // line 9
 true + true -> 4 // line 10

Feb 27 2006
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Walter Bright schrieb am 2006-02-27:
 "Thomas Kuehne" <thomas-dloop kuehne.cn> wrote in message 
 news:0fo9d3-mb8.ln1 birke.kuehne.cn...
 # import std.stdio;
 #
 # int main(){
 # int i = 3;
 # bool a = true;

The next line goes around the type system completely, invalidates any invariants on the contents, and so any "surprising" results should be unsurprising:
 # bool b = *(cast(bool*)cast(void*) &i);


I was sure there was another way to subvert without casting though can't find it right now. related suggestion: a) if( a == b ) { ... } b) if( a != b ) { ... } If, after constant folding, the lines above results in a) if( a == true ) { ... } b) if( a != true ) { ... } then the the code a) if( a != false ) { ... } b) if( a == false ) { ... } is generated. consequences: 1) no changes in the D documentation are required 2) no runtime overhead 3) the code is a bit more robust against casting and bools returned from external sources (e.g. C code) Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFEBOB93w+/yD4P9tIRAlJpAJ9IdclZxNNPVFIEl0N/jLrwlC1EAACeNnGi 4fXZOJBKlc/5ES50zb21khs= =HMVz -----END PGP SIGNATURE-----
Feb 28 2006
parent "Walter Bright" <newshound digitalmars.com> writes:
"Thomas Kuehne" <thomas-dloop kuehne.cn> wrote in message 
news:2t3fd3-hm9.ln1 birke.kuehne.cn...
 3) the code is a bit more robust against casting and bools returned
 from external sources (e.g. C code)

That's true, but I disagree with the intent. When interfacing with C, or doing casting, it's up to you to get the right results into the variable to satisfy the constraints of the type. Having the compiler essentially hide bugs of this sort doesn't make it robust, it just defers the problem to cropping up somewhere else.
Feb 28 2006
prev sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Mon, 27 Feb 2006 04:36:08 +1100, Charles <noone nowhere.com> wrote:

  > Can't we simply treat zero as false and non-zero as true as we C
  > programmers always do?

 I agree, I still don't get what the 'true bool' fuss is about .

Should a coder be allowed by the compiler to perform arithemtic operations of booleans? -- Derek Parnell Melbourne, Australia
Feb 26 2006
parent reply Georg Wrede <georg nospam.org> writes:
Derek Parnell wrote:
 On Mon, 27 Feb 2006 04:36:08 +1100, Charles <noone nowhere.com> wrote:
 
  > Can't we simply treat zero as false and non-zero as true as we C
  > programmers always do?

 I agree, I still don't get what the 'true bool' fuss is about .

Should a coder be allowed by the compiler to perform arithemtic operations of booleans?

No. And that's why nobody (to my knowledge) is opposing _having_ booleans.
Feb 26 2006
parent Derek Parnell <derek psych.ward> writes:
On Mon, 27 Feb 2006 00:34:07 +0200, Georg Wrede wrote:

 Derek Parnell wrote:
 On Mon, 27 Feb 2006 04:36:08 +1100, Charles <noone nowhere.com> wrote:
 
  > Can't we simply treat zero as false and non-zero as true as we C
  > programmers always do?

 I agree, I still don't get what the 'true bool' fuss is about .

Should a coder be allowed by the compiler to perform arithemtic operations of booleans?

No. And that's why nobody (to my knowledge) is opposing _having_ booleans.

Then why the objection to having them as booleans rather than numbers? One purpose for having a compiler is to help coders reduce the number of mistakes that they could make. And one of the reasons we have a type system in compilers is to catch a set of potential mistakes that coders make. If we pretend that booleans are number types, we deny an opportunity to catch potential coding mistakes. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 27/02/2006 9:53:51 AM
Feb 26 2006
prev sibling next sibling parent John Reimer <terminal.node gmail.com> writes:
Walter Bright wrote:
 Lots of new stuff, I added new threads for them in the digitalmars.D 
 newsgroup.
 
 http://www.digitalmars.com/d/changelog.html
 
 

:P New releases with bug fixes are always welcome, and I'm excited at the possibility of improvements with new features... Yet I'm just a little concerned about the recent additions of these new features. It looks like you've already begun ramping up for your experimental fork planned for post 1.0. It's definitely good to see you practicing for that! :D But I'm worried that this is being done /before/ release 1.0. Isn't bug fixing supposed to be the highest priority now? Okay... I'll keep quite, now. -JJR
Feb 25 2006
prev sibling next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Walter Bright schrieb am 2006-02-26:
 Lots of new stuff, I added new threads for them in the digitalmars.D 
 newsgroup.

 http://www.digitalmars.com/d/changelog.html

Missing from the changelog: added DMD Script Shell http://www.digitalmars.com/d/rdmd.html Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFEAVhF3w+/yD4P9tIRAqh3AKCQdzlVeGTLvmBAM8hQlk01WFKUlACeIQ6R pX7C/c/3ctdZ7xqjJ06VnqI= =rLQz -----END PGP SIGNATURE-----
Feb 25 2006
parent reply Dave <Dave_member pathlink.com> writes:
In article <6r18d3-3l7.ln1 birke.kuehne.cn>, Thomas Kuehne says...
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Walter Bright schrieb am 2006-02-26:
 Lots of new stuff, I added new threads for them in the digitalmars.D 
 newsgroup.

 http://www.digitalmars.com/d/changelog.html

Missing from the changelog: added DMD Script Shell http://www.digitalmars.com/d/rdmd.html Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFEAVhF3w+/yD4P9tIRAqh3AKCQdzlVeGTLvmBAM8hQlk01WFKUlACeIQ6R pX7C/c/3ctdZ7xqjJ06VnqI= =rLQz -----END PGP SIGNATURE-----

With an eye toward integrating rdmd with the compiler (as is mentioned in the doc), if anyone has the time, please review the rdmd source code to spot any potential security issues, subtle bugs, etc. The most recent version of the source code (for both *nix and Windows) is here: digitalmars.D.announce/2673 Thanks, - Dave
Feb 26 2006
parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave schrieb am 2006-02-26:
 In article <6r18d3-3l7.ln1 birke.kuehne.cn>, Thomas Kuehne says...

[snip]
Missing from the changelog:

added DMD Script Shell
http://www.digitalmars.com/d/rdmd.html


 With an eye toward integrating rdmd with the compiler (as is mentioned in the
 doc), if anyone has the time, please review the rdmd source code to spot any
 potential security issues, subtle bugs, etc.

 The most recent version of the source code (for both *nix and Windows) is here:
 digitalmars.D.announce/2673

The argument parsing didn't seem to be very robust. Thomas
Feb 26 2006
prev sibling next sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:
 Lots of new stuff, I added new threads for them in the digitalmars.D 
 newsgroup.

Cool things added, cool things removed but when is bool going to be added? <g> ;)
Feb 26 2006
prev sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter Bright wrote:
 Lots of new stuff, I added new threads for them in the digitalmars.D 
 newsgroup.
 
 http://www.digitalmars.com/d/changelog.html

FWIW, here's a(nother) practical example why bools-that-are-not-ints would be useful. I hit this bug in my own, real-world code, *TODAY*. I am writing a small compiler. In it, I build parse trees and expression trees. Some of these types had a field 'is_array'. Today I decided that it would be better to store the array length instead, so I replaced 'is_array' with 'array_length in each struct. I then had to modify all of the code that used those fields. In a dozens of places I had tests like: if(expr->value.is_array) which I needed to convert to if(expr->value.array_length > 0) Yet, in a number of cases, I ended up doing, instead: if(expr->value.array_length); Likewise, at least once I turned a test like if(!expr->value.is_array) into if(!expr->value.array_length > 0) Which are very hard to find...I'm just gradually finding these problems as I run my test suite on the program. They would have been compile errors if bools and ints didn't have implicit casts between them.
Mar 07 2006