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.


  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,


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.


 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??


 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.


 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??
 

 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 :-)
 


Which although not a critical issue, still has some some things that 
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;



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


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 


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).
 


Don't hamper D because of that. Better solution then is to keep that 
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!


 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.


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!


 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.


 
 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!


 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.


 
 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" :(


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!


 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.


 
 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!


 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.


 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 :)


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!


 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.


 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 :)


 
 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" :)




 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" :)
 

 


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)



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!


 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.


 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 :)


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?





 

 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.


  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,


 
 
 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.


  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,



 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.


  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,


   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.


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.


   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.


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?


















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...








The next line goes around the type system completely, invalidates any 
invariants on the contents, and so any "surprising" results should be 
unsurprising:















 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...








 The next line goes around the type system completely, invalidates any 
 invariants on the contents, and so any "surprising" results should be 
 unsurprising:







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:
http://www.digitalmars.com/drn-bin/wwwnews?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:
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.announce/2673


The argument parsing didn't seem to be very robust.

Thomas

begin 644 rdmd.zip

M `,"1%5X!`#H
M'.`S!$I<26SX*I>4[";.;^_,[(/+ARPW:`U8%G=GY[7SI \.6![$`>LSGV5Y
MNLS]F!4IFZ=Q%D:\Q^;^?,69GP2,W_)Y67!VHN'B,%D^W3LX8)&?+$M_R9E(



M\YS[1;CFR'B:B$&:+P_ )$\$%P<2BT1B&)FL0 $Z6!0;/^<,OH.BUF$`6)VC
M*W9ZY1!+&]!)6A;P_0[IYEP(T`<A".,L" $<SN=^4H1<](#Q>50&*+Y].`KC
ML`#V0$U%VD-<A$`=O&/I L4\GZ_ P9^%48A+.5Q,D2"Y!>H?R&=EGJ6"5ZI<
M\UP SA>#X=,]6GDY'+[J#U_V7[X"\4!<P?Y>\A5<X2\%/?[M,ST.YLD; O^1




M!>QU#O8A'^`W3/77'"Y0P?C%BB3UHQ"L02\-!,_(\:\XW+=?I/FH!8(?"(9_

M*J%;02Q`AC2^'IK]W$:/H`;O/,[6/<2^'N$ZV"JN`+0*A;DQ:"'!8$L'3+-C




M=YVXC(HPBQKI#D)^\AS\3#LF7

M&A9RS6UH-#O*?3NTU8U4!90=:*NP\P#B]NJ7;J2UJ#X7C!C17G_HC+I/2;8K


M)R6H;UM"A^$'>=`QPN)#Q;GCM(P"C&F+$,LYJ!=/=,B;IX&,>U:O `6FZA$&
MM>!G:"E`5^J^I\VQ1X[=J[(DI6*5/;UV[C$I&T`H7UN<RQ647)VW-G62:V2W
MM6<?DPJKY2X5(+RMD7:Q 0Z$+UPH=$!U/2<ODP32\6OF>(V[ZV)!$=\=FAMD

MIZ/32:^JB;34WY'8ZK3\+',UUNU(U9\*KUU'Y7?LBRF)!SF/TS77.+T1NX<F
MN)BOV)?[[2[2] 'FL&]6%O\&A4?-*VH7`,MEGJA=7;DK(Y%%&RRNTS!0A'6%



M<(14KE;IA 6\\$%/..)8I$ CS7A.!$4'"0%'=E$PY8H++<K7)7QX0"OC\W!Q

M?A[RFGC8/'V'53CG:<%W6`*.Q\"O40\L+J&>F4&=F<BA5IGG..(HH>FFWH??
M%NS9Y='DW6.=(DA!#KH8V3BH

MLK60N5YOVIUQO1$/$QQSU3OI+6W_T"1L`779O)CB*$2BQF\CRFT=I0MNEH+<
M9E"AA:T<>WO<=2O^] V^JJ0Q+",$RBDH*46A?;`V$_%&S0F!Z `-ANMG_1>Z
M`-5"T6`'"A%[2*0*5D\IY(G<IH!I*N<.>-6*0B6MH(%>!UC5+MN;V`SK9KEB

MR]BY.\V.3Y.`^LZAO(SG-1M '.]/? +_B]'CVAE*0I6SNX)?OW %-ALNP0X4

M2 ($$HY,B"88MNE=#V\:6E%8OQVVYG:&9[A*VJ2Q$8[AP;$ &<Y\04O], SZ
M),.="/BZ#TX;\#YHTR"`Z QGP9:"U;N`AI(A2JGY/%D5T8.%A4JC.GR%=/Z.
M9B=H/\F2!SI&Z6F)%LN8*%A3'R_='I,!XZ[GM;>,EP]$,061=H&`Q!6(-(2)
M`:1'3W)B/*(S6`&`"E6D-6D<,D[[LZVA" "J4*5KX'V%2X<:,`NIQ:]?V:X?
M("UAK:K%V(RD]C L))0L:CFVCK)L92X?+`>O(=WINZDLLJ;5N`CA_M]HM51+
M0!VQ-R,YF&3"-_2B"6D9O1GL6$:0EM0(U'L$E6(EW^!0_?%X"MJV'R3AR0&S


M9/%<+0R.NW7E8WMO=?<R.RFCJ<J5+N!'EB5&P/8('E^MY<M\7;]5'-:XBH-&
M\<'>M`?VA$''$'V,[6LN[>M]L"FGUY\\Y\\%6T(U"[$;JF0?/HH"['KCWPT&
M T92MJLGN*BJ>&J]SY`%M=>KO3C:,5M!<S>H=P]7:GJ09E-3'CP_K)WJ"IBK

M4(&3$L- 6N"GG-9_=FOC/US_`=_2=;Y.HE-UC34TA7%Q[1K.FI,>_`'32]D9
M)9MM<Z[-"GN5%]O)D#K(!QO(I70;*=[&#POXAFR

MW(<PJ+K -GKKQ>+NZ?<CS*`Y<3,`\MAKXT12`1")QC ATY6W&O_Y";7NZ#RL



MQ8#EIS8V ZFN(JAL4(R_CJ2YW;/JWVY,4-[^KS#R
MXML$:DSWW='YR=F8K=[2/WJ<7;X]/1M/3M^/690=T_\VI0G"];:\[:H=.`-M
M',UQED]'VIOX3UA$5EN79N>CX/DY>,*1>W8YN9I\`/A?R\4"!T)GER>?+CZ<
ML.0J_+<ZIWP4&Q'_,U>%$ZD4E\VC*:<L^<LH399,MFW:PN5]8)<V: !1&=Y-




M01OTSD\"*`Q65M_1V2<9T=K=$5H#MD8F?E,&Z#D,%UMO?KJS4,,:97"NV:.J

MJA*IQD1=6L?IDI0ZP)J ]!)*-H;0/%2"WE.B^ ]02P,$%``"`` `XJ1:-!E5



M]0(G"(/ PG&<6B4\I3*>'*DL%N"%H3NZ`P>W\006BPNXN;FD!^R8D+S(`2-`
MPN6% [2.T8^;(HLD_+YEFYS!KTI_+C[K3S_.'RJ%7V`3B83E"41BO<U8KJ",


M/2N6ZW!0PD=:7X ]L[X$$DC"08DBE^H-Q Y%SYF$/3IFJ62H0EN-TS#E^?;Y

M$A L ?<?+)L4!E)%BL<02<F$& :V09: 619%2J N"T1W#JL

M(+E>?DQR_[M(R?$9/-`1<.SI+.+YL$H.I =;O>Y4FC"W8Q<'S"1TP[$>,/7B
MJR&'^1P"^[(ETL)<*RQ3UI1I([_"!A^B>=?R$\N&!U0&^/8-H,N0AF/KPFET
M ?A^RO*UVL`#D(7ZZ_J:8GZ\`J]']GVX>J((M;>.M0&Z/+(FSYB3)^U1D-US
MZY(UD6ZB':,LP4\&:;MF:JD!$Z(00RO;IHJ7*":+K8B9KA:)GEG^,^:]+G?+
M!<'4+DJKFB<K^P.\&W]S4**"O;L2XE&)(1_/U67OJPQ/WU%NG;OI88H/LMIV
M<"RI;STO+K(2K8NY=>BUD[D>TK$\ #GP_8:FT8VE?<;62Z>:CL.K(L&X9(GW





M;;$J!(OBC;FN$!PQ0\URAY']`U!+`0(7`Q0`` `(`+*D6C1P;ETE0`T``+DJ


G9&EF9E54!0`#UP,"1%5X``!02P4&``````(`` "%````>A$`````
`
end

-----BEGIN PGP SIGNATURE-----

iD8DBQFEAgSk3w+/yD4P9tIRAnqhAKCrgbSs/zGTwVZYVo2qZiBiQSo0twCeKKjM
UsbpRPYlvjigBibMLh7iZZI=
=BiW7
-----END PGP SIGNATURE-----
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