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

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

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

Regan Heath schrieb am 2006-02-26:
> On Sun, 26 Feb 2006 18:46:10 +0000 (UTC), Thomas Kuehne
><thomas-dloop@kuehne.cn> wrote:
>> Charles schrieb am 2006-02-26:
>>>
>>> > Can't we simply treat zero as false and non-zero as true as we C programmers always do?
>>>
>>> I agree, I still don't get what the 'true bool' fuss is about .
>>
>> if(b==1) { ... }
>>
>> instead of
>>
>> if(b!=0) { ... }
>>
>> can be found in quite a lot of C code ...
>
> So?
>
> Assuming:
>
>   - 'b' is a bool
>   - a bool can only have 2 values, 'true' and 'false'
>   - when you convert/promote a bool to an int you get: 'true'->'1',
> 'false'->'0'
>   - when you convert/promote an int to bool you get: '0'->false,
> '!0'->'true'
>
> Then:
>
> if(b==1) { ... }
>
> results in 'b' being converted to int, giving it the value 1, and the comparrison working correctly.
>
> Right?


# import std.stdio;
#
# int main(){
#	int i = 3;
#	bool a = true;
#	bool b = *(cast(bool*)cast(void*) &i);
#
#	writefln("a: %s", a);
#	writefln("b: %s", b);
#	writefln("int: %s", cast(int)b); // line 9
#	writefln("a+b: %s", a+b); // line 10
#
#	return 0;
# }

I know, nobody writes code like that ...

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

>   - when you convert/promote a bool to an int you get: 'true'->'1',
> 'false'->'0'

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

Thomas

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>

;)

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

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?

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.

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

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