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

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.

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

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

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)

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

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 bool as it is. But if I can recall someone said in another post, languages as C# has pure booleans implemented: I don't see people crying about C# because of it. 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;

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

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 C++/Java/C# and probably most other users.

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.

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.