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.

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

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;

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

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");
  }

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

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

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.

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

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