Bruno Medeiros wrote:
> 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.
>>
> 
> Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what you meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight.
> 
> What exactly is it in bools that you Walter, want and not want?
> I already know that the ability to write 'while(1)' as the same as 'while(true)' is one of them, but, anything more?
> Is the behaviour of having an "implicit promotion" something you want too?
> If so, promotion from where, from int to bool, or from bool to int?
> Do you want or not want bool numeric operations to be an error (like boolA / boolB*2) ?


I think one use case that is important is to be able to use bool to connect to C APIs (such as the Windows SDK) that use BOOL (a short).

Interestingly, you only need this for extern(C), extern(Windows) declarations. It would be fantastic if there was a way to specify that
an extern function is actually a synthetic bool.

The ability to say
if (p || q) {}
instead of
if (p !is null || q !is null) {}
is important too.

I too would like to know if Walter has more.

In article <du71jc$1e9h$1@digitaldaemon.com>, Bruno Medeiros says...
>
>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.
>> 
>
>Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what you meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight.
>
>What exactly is it in bools that you Walter, want and not want?
>I already know that the ability to write 'while(1)' as the same as
>'while(true)' is one of them, but, anything more?
>Is the behaviour of having an "implicit promotion" something you want too?
>If so, promotion from where, from int to bool, or from bool to int?
>Do you want or not want bool numeric operations to be an error (like
>boolA / boolB*2) ?

You should read the latest posts about this stuff (the most with subject "Re: DMD 0.148 release"). It's all said there. By "pure bools" I mean the *purist kind* of boolean type. A boolean type that abstracts us from the implementation.

Tom;

Tom wrote:
> In article <du71jc$1e9h$1@digitaldaemon.com>, Bruno Medeiros says...
>> 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.
>>>
>> Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what you meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight.
>>
>> What exactly is it in bools that you Walter, want and not want?
>> I already know that the ability to write 'while(1)' as the same as 'while(true)' is one of them, but, anything more?
>> Is the behaviour of having an "implicit promotion" something you want too?
>> If so, promotion from where, from int to bool, or from bool to int?
>> Do you want or not want bool numeric operations to be an error (like boolA / boolB*2) ?
> 
> You should read the latest posts about this stuff (the most with subject "Re:
> DMD 0.148 release"). It's all said there. By "pure bools" I mean the *purist
> kind* of boolean type. A boolean type that abstracts us from the implementation.

Sorry, that's still not clear.
Bruno is right, terms like "pure bools" or "purist bools" are vague, you can't expect everyone to know what you mean.

For example: do you want "&" to be legal for bool types, or just "&&"?
(they mean very different things for integers). "&" normally means "bitwise and", but a pure bool doesn't have any bits.
Is it legal to cast from a bool to some other type?

> A boolean type that abstracts us from the implementation.

No abstraction is perfect. Does a bool have a defined bit representation? (If you say 'no' to this, then I don't think a bool could be used in an extern function, you'd always have to convert it to int or something).

You need a comprehensive list of which operations are legal, and which are not.

Don Clugston wrote:
> Tom wrote:
>> In article <du71jc$1e9h$1@digitaldaemon.com>, Bruno Medeiros says...
>>> 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.
>>>>
>>> Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what you meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight.
>>>
>>> What exactly is it in bools that you Walter, want and not want?
>>> I already know that the ability to write 'while(1)' as the same as 'while(true)' is one of them, but, anything more?
>>> Is the behaviour of having an "implicit promotion" something you want too?
>>> If so, promotion from where, from int to bool, or from bool to int?
>>> Do you want or not want bool numeric operations to be an error (like boolA / boolB*2) ?
>>
>> You should read the latest posts about this stuff (the most with subject "Re:
>> DMD 0.148 release"). It's all said there. By "pure bools" I mean the *purist
>> kind* of boolean type. A boolean type that abstracts us from the implementation.
> 
> Sorry, that's still not clear.
> Bruno is right, terms like "pure bools" or "purist bools" are vague, you can't expect everyone to know what you mean.
> 
> For example: do you want "&" to be legal for bool types, or just "&&"?
> (they mean very different things for integers). "&" normally means "bitwise and", but a pure bool doesn't have any bits.
> Is it legal to cast from a bool to some other type?
> 
>  > A boolean type that abstracts us from the implementation.
> 
> No abstraction is perfect. Does a bool have a defined bit representation? (If you say 'no' to this, then I don't think a bool could be used in an extern function, you'd always have to convert it to int or something).
> 
> You need a comprehensive list of which operations are legal, and which are not.

I tend to want a boolean that is an operand of the boolean algebra and nothing else. So it is either true or false, independant of implementation, integer operations are illegal, and it cant be cast to anything.

Don Clugston wrote:
> Tom wrote:
>> In article <du71jc$1e9h$1@digitaldaemon.com>, Bruno Medeiros says...
>>> 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.
>>>>
>>> Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what you meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight.
>>>
>>> What exactly is it in bools that you Walter, want and not want?
>>> I already know that the ability to write 'while(1)' as the same as 'while(true)' is one of them, but, anything more?
>>> Is the behaviour of having an "implicit promotion" something you want too?
>>> If so, promotion from where, from int to bool, or from bool to int?
>>> Do you want or not want bool numeric operations to be an error (like boolA / boolB*2) ?
>>
>> You should read the latest posts about this stuff (the most with subject "Re:
>> DMD 0.148 release"). It's all said there. By "pure bools" I mean the *purist
>> kind* of boolean type. A boolean type that abstracts us from the implementation.
> 
> Sorry, that's still not clear.
> Bruno is right, terms like "pure bools" or "purist bools" are vague, you can't expect everyone to know what you mean.
> 
> For example: do you want "&" to be legal for bool types, or just "&&"?
> (they mean very different things for integers). "&" normally means "bitwise and", but a pure bool doesn't have any bits.
> Is it legal to cast from a bool to some other type?
> 
>  > A boolean type that abstracts us from the implementation.
> 
> No abstraction is perfect. Does a bool have a defined bit representation? (If you say 'no' to this, then I don't think a bool could be used in an extern function, you'd always have to convert it to int or something).
> 
> You need a comprehensive list of which operations are legal, and which are not.

Exactly, the "pure bools" must be defined by a set of language behaviors. Derek made a post some time ago with one such definition (news://news.digitalmars.com:119/14shfnb64x5o2.17cec6fac7wnu.dlg@40tude.net).

However, the problem is, and the reason I opened this thread, that in the previous discussion people started getting lost in a too vague or incongruous debate of "pure bools" vs. being able to use "while(1)" and implicit conversions and whatnot (arguing about things that are not on the same level).
What I'm trying to say is, that of that set of bool behaviors, it is not an all or nothing situation, it is a gradient of behaviors. Just a part of them can be implemented, and if all Walter wants is the ability to do "while(1)" or 'implicit conversion of integers to bool' (which are the only counter-points I've seen so far), then there is still a lot of other things that can me made to improve bool:

We could have:
* Conditional expressions should be of type bool
* Integers can be implicitly converted to bool, as Walter wants. (where 0 is false, the rest is true). This allows for "while(1)" .
* Pointer and references can be implicitly converted too (where null is false, the rest is true). This allows for "if(objFoo)" .
* No numeric operations are allowed on bool, just boolean operations.
* bool can only be explicitly cast to a numeric type.
* Regardless of bool implementation, it has only two abstract states: true or false, and conversions from int should be aware of that. For instance this should 'then':
  if (2==true) writefln("then");  // doesnt "then" :(

It won't be the "purest" of bools (like Java or C# or other languages), because of the second feature, but it's still a lot better than what we have. Walter what's your take? Do you have any problem with any of these behaviors?

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

Don Clugston wrote:
> Bruno Medeiros wrote:
>> 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.
>>>
>>
>> Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what you meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight.
>>
>> What exactly is it in bools that you Walter, want and not want?
>> I already know that the ability to write 'while(1)' as the same as 'while(true)' is one of them, but, anything more?
>> Is the behaviour of having an "implicit promotion" something you want too?
>> If so, promotion from where, from int to bool, or from bool to int?
>> Do you want or not want bool numeric operations to be an error (like boolA / boolB*2) ?
> 
> 
> I think one use case that is important is to be able to use bool to connect to C APIs (such as the Windows SDK) that use BOOL (a short).
> 
Don't hamper D because of that. Better solution then is to keep that separate from D's bool, no? :
  alias BOOL short.



-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

In article <du9cnl$2h9j$3@digitaldaemon.com>, Bruno Medeiros says...
>
>Don Clugston wrote:
>> Tom wrote:
>>> In article <du71jc$1e9h$1@digitaldaemon.com>, Bruno Medeiros says...
>>>> 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.
>>>>>
>>>> Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what you meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight.
>>>>
>>>> What exactly is it in bools that you Walter, want and not want?
>>>> I already know that the ability to write 'while(1)' as the same as
>>>> 'while(true)' is one of them, but, anything more?
>>>> Is the behaviour of having an "implicit promotion" something you want
>>>> too?
>>>> If so, promotion from where, from int to bool, or from bool to int?
>>>> Do you want or not want bool numeric operations to be an error (like
>>>> boolA / boolB*2) ?
>>>
>>> You should read the latest posts about this stuff (the most with
>>> subject "Re:
>>> DMD 0.148 release"). It's all said there. By "pure bools" I mean the
>>> *purist
>>> kind* of boolean type. A boolean type that abstracts us from the
>>> implementation.
>> 
>> Sorry, that's still not clear.
>> Bruno is right, terms like "pure bools" or "purist bools" are vague, you
>> can't expect everyone to know what you mean.

[snip]

>Derek made a post some time ago with one such definition (news://news.digitalmars.com:119/14shfnb64x5o2.17cec6fac7wnu.dlg@40tude.net).

And that is exactly what I meant when I said that you should read the latest posts on the stuff :)


Tom;

Tom wrote:
> In article <du9cnl$2h9j$3@digitaldaemon.com>, Bruno Medeiros says...
>> Don Clugston wrote:
>>> Tom wrote:
>>>> In article <du71jc$1e9h$1@digitaldaemon.com>, Bruno Medeiros says...
>>>>> 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.
>>>>>>
>>>>> Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what you meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight.
>>>>>
>>>>> What exactly is it in bools that you Walter, want and not want?
>>>>> I already know that the ability to write 'while(1)' as the same as 'while(true)' is one of them, but, anything more?
>>>>> Is the behaviour of having an "implicit promotion" something you want too?
>>>>> If so, promotion from where, from int to bool, or from bool to int?
>>>>> Do you want or not want bool numeric operations to be an error (like boolA / boolB*2) ?
>>>> You should read the latest posts about this stuff (the most with subject "Re:
>>>> DMD 0.148 release"). It's all said there. By "pure bools" I mean the *purist
>>>> kind* of boolean type. A boolean type that abstracts us from the implementation.
>>> Sorry, that's still not clear.
>>> Bruno is right, terms like "pure bools" or "purist bools" are vague, you can't expect everyone to know what you mean.
> 
> [snip]
> 
>> Derek made a post some time ago with one such definition (news://news.digitalmars.com:119/14shfnb64x5o2.17cec6fac7wnu.dlg@40tude.net).
> 
> And that is exactly what I meant when I said that you should read the latest
> posts on the stuff :)

And if you read that post, you will find that Derek said:

** It can be explicitly cast to an integer such that false is 0, and true is 1.

whereas Kyle said:

integer operations are illegal, and it cant be cast to anything.

So there are at least four types of bool being discussed. Probably more.
And at least two can be called "pure bool".
(a) the existing bool
(b) Bruno and I are in here somewhere, and are not necessarily the same.
(c) Derek
(d) Kyle

Right now, (a) and (c) are the only ones which are clearly defined.

Don Clugston wrote:
> Tom wrote:
>> In article <du9cnl$2h9j$3@digitaldaemon.com>, Bruno Medeiros says...
>>> Don Clugston wrote:
>>>> Tom wrote:
>>>>> In article <du71jc$1e9h$1@digitaldaemon.com>, Bruno Medeiros says...
>>>>>> 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.
>>>>>>>
>>>>>> Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what you meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight.
>>>>>>
>>>>>> What exactly is it in bools that you Walter, want and not want?
>>>>>> I already know that the ability to write 'while(1)' as the same as 'while(true)' is one of them, but, anything more?
>>>>>> Is the behaviour of having an "implicit promotion" something you want too?
>>>>>> If so, promotion from where, from int to bool, or from bool to int?
>>>>>> Do you want or not want bool numeric operations to be an error (like boolA / boolB*2) ?
>>>>> You should read the latest posts about this stuff (the most with subject "Re:
>>>>> DMD 0.148 release"). It's all said there. By "pure bools" I mean the *purist
>>>>> kind* of boolean type. A boolean type that abstracts us from the implementation.
>>>> Sorry, that's still not clear.
>>>> Bruno is right, terms like "pure bools" or "purist bools" are vague, you can't expect everyone to know what you mean.
>>
>> [snip]
>>
>>> Derek made a post some time ago with one such definition (news://news.digitalmars.com:119/14shfnb64x5o2.17cec6fac7wnu.dlg@40tude.net). 
>>>
>>
>> And that is exactly what I meant when I said that you should read the latest
>> posts on the stuff :)
> 
> And if you read that post, you will find that Derek said:
> 
> ** It can be explicitly cast to an integer such that false is 0, and true is 1.
> 
> whereas Kyle said:
> 
> integer operations are illegal, and it cant be cast to anything.
> 
> So there are at least four types of bool being discussed. Probably more.
> And at least two can be called "pure bool".
> (a) the existing bool
> (b) Bruno and I are in here somewhere, and are not necessarily the same.
> (c) Derek
> (d) Kyle
> 
> Right now, (a) and (c) are the only ones which are clearly defined.

Hmm, how about an expansion of (d):

1) still allow implicit casts to bool from any type, as in
- value != 0
- obj_ref !is null
- pointer !is null
- array.ptr !is null
- !struct.opEquals(0) // does this work now?

2) forbid casts from bool to anything else (even explicit; besides "foo?1:0" is shorter and more obvious than "cast(int)foo")

3) when an expression involves a bool operand, all other operands get converted to bool

4) forbid all operators on bools, except ==, !=, &&, ||, &, |, and !. (& and | don't short-circuit evaluation, but are otherwise equivalent to && and ||).


Then, the purists should be satisfied, because the only operations allowed are the logic ones, and true and false don't have a numeric representation.

There is a true/false representation of everything else, though, allowing all the short forms we like, like

while(1)
if (foo && foo.bar())
if (refA || refB)


xs0

In article <du9ff8$2ltg$1@digitaldaemon.com>, Don Clugston says...
>
>Tom wrote:
>> In article <du9cnl$2h9j$3@digitaldaemon.com>, Bruno Medeiros says...
>>> Don Clugston wrote:
>>>> Tom wrote:
>>>>> In article <du71jc$1e9h$1@digitaldaemon.com>, Bruno Medeiros says...
>>>>>> 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.
>>>>>>>
>>>>>> Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what you meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight.
>>>>>>
>>>>>> What exactly is it in bools that you Walter, want and not want?
>>>>>> I already know that the ability to write 'while(1)' as the same as
>>>>>> 'while(true)' is one of them, but, anything more?
>>>>>> Is the behaviour of having an "implicit promotion" something you want
>>>>>> too?
>>>>>> If so, promotion from where, from int to bool, or from bool to int?
>>>>>> Do you want or not want bool numeric operations to be an error (like
>>>>>> boolA / boolB*2) ?
>>>>> You should read the latest posts about this stuff (the most with
>>>>> subject "Re:
>>>>> DMD 0.148 release"). It's all said there. By "pure bools" I mean the
>>>>> *purist
>>>>> kind* of boolean type. A boolean type that abstracts us from the
>>>>> implementation.
>>>> Sorry, that's still not clear.
>>>> Bruno is right, terms like "pure bools" or "purist bools" are vague, you
>>>> can't expect everyone to know what you mean.
>> 
>> [snip]
>> 
>>> Derek made a post some time ago with one such definition (news://news.digitalmars.com:119/14shfnb64x5o2.17cec6fac7wnu.dlg@40tude.net).
>> 
>> And that is exactly what I meant when I said that you should read the latest posts on the stuff :)
>
>And if you read that post, you will find that Derek said:
>
>** It can be explicitly cast to an integer such that false is 0, and true is 1.
>
>whereas Kyle said:
>
>integer operations are illegal, and it cant be cast to anything.
>
>So there are at least four types of bool being discussed. Probably more.
>And at least two can be called "pure bool".
>(a) the existing bool
>(b) Bruno and I are in here somewhere, and are not necessarily the same.
>(c) Derek
>(d) Kyle
>
>Right now, (a) and (c) are the only ones which are clearly defined.

You are right. So lets just call (c) "Derek's Bool". And now that the definition has been made, I vote for "Derek's Bool" :D

Tom;