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

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

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

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

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

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

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

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

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

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