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

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.

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;

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

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

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.

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

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

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

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