xs0 wrote:
> 
> 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.
> 

Ok, I (as a bool purist) will not be satisfied with that & and | part.
& and | are not logic operations but bit operations.

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

Yuck, but I would agree with it as long as conditions have to be booleans. I know it isn't a perfect world and although I would never use the above, it would still be better than what we have now (as long as all the other conditions are satisified).

Don Clugston wrote:
>>
>> 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 "&&"?

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?

I'm not against casting but implicit conversions are bad.

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

I think D ABI should define an internal representation, but it should be abstracted from the user, so that the user doesn't have tok know anything about it.

You make a good point about passing bool to extern functions, but one could argue that even right now you are calling extern functions using bools with a couple assumptions in mind. For example that the function uses 0==false and true==everything but 0. But that doesn't have to be true.

Ivan Senji wrote:
> xs0 wrote:
>>
>> 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.
>>
> 
> Ok, I (as a bool purist) will not be satisfied with that & and | part.
> & and | are not logic operations but bit operations.

They are bitwise operations on integers, because that's what they're defined to be. We're free to define them to do something else on booleans, which I propose to be [what I said above].

BTW, even Java, which has a really purist boolean implementation, uses those for exactly the stated purpose (and even calls them "logical operators", while && and || are "conditional-and" and "-or" :)

http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.5

>> 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)
> 
> Yuck, but I would agree with it as long as conditions have to be booleans. I know it isn't a perfect world and although I would never use the above, it would still be better than what we have now (as long as all the other conditions are satisified).

I used to think so too, until I was forced to code in Java :) Even though I don't mind typing something as simple as

if (a!=null)

the verbosity of longer expressions really annoys the heck out of me. Now, I prefer

> if (a && b && c && d) // check for nulls
>    ...

to

> if (a!=null && b!=null && c!=null && d!=null)
>    ...

or D's even verboser

> if (a !is null && b !is null && c !is null || d !is null)
>    ...

Note how the vars that are being tested get lost in there.. BTW, did you notice the last line is not equivalent? :)


xs0

xs0 wrote:
> Don Clugston wrote:
>> 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):

Yes, this is very similar to the definition I have suggested. I think this is a good compromise:

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

This would mean that we would keep if(a && b) and also that the type of any conditional could be defined as bool. But it would also mean that you could write bool b = 5; I guess.

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

I can live with explicit cast both being allowed and not. I don't see it as an important detail. The important part is to disallow implicit casts from bool to any type.

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

This is the logical conclusion from 1) and 2).

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

For consistency, ~ should be supported too. And ^ too of course.

/Oskar

Ivan Senji wrote:
> Don Clugston wrote:
>> 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 "&&"?
> 
> Just &&.

Why? Ever heard of boolean algebra? Why should &,|,^,~ not be defined and allowed for bool? It would be problematic and inconsistent not having non-short-circuit operators for booleans.

>> (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?
> 
> I'm not against casting but implicit conversions are bad.

Do you mean that all implicit conversions are bad? Are the integer promotion rules bad?

/Oskar

Oskar Linde wrote:
> Ivan Senji wrote:
> 
>> Don Clugston wrote:
>>
>>> 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 "&&"?
>>
>>
>> Just &&.
> 
> 
> Why? Ever heard of boolean algebra? 

Ever heard of logic operators && and ||? That is what they are for.

> Why should &,|,^,~ not be defined and allowed for bool? It would be problematic and inconsistent not having non-short-circuit operators for booleans.

I learned from xs0's reply that Java uses &,| for non-short-circuit evaluation when arguments are of type bool. As D doesn't have a bool in the Java meaning I don't think making & anything but bitwise operator makes sense.

> 
>>> (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?
>>
>>
>> I'm not against casting but implicit conversions are bad.
> 
> 
> Do you mean that all implicit conversions are bad? Are the integer promotion rules bad?

Ofcourse not. But with bools yes.

Do you think:
bool b = 5; would be a good thing?

int x = b/3; would be a good thing?

Ivan Senji wrote:

> Oskar Linde wrote:
>> Ivan Senji wrote:
>> 
>>> Don Clugston wrote:
>>>
>>>> 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 "&&"?
>>>
>>>
>>> Just &&.
>> 
>> 
>> Why? Ever heard of boolean algebra?
> 
> Ever heard of logic operators && and ||? That is what they are for.

&& and || controls the program flow. They are not algebraic operators. &,|,~,^ are real operators that also maps directly onto machine instructions on most cpu architectures. Their meaning would be well defined for bools. && and || requires branching and are therefore much less efficient (even though this can be optimized away in many cases).

Also, not allowing ^ for bools would mean that code that reads a^b today would have to be rewritten as:

(a && !b) || (!a && b).

>> Why should &,|,^,~ not be defined
>> and allowed for bool? It would be problematic and inconsistent not
>> having non-short-circuit operators for booleans.
> 
> I learned from xs0's reply that Java uses &,| for non-short-circuit evaluation when arguments are of type bool. As D doesn't have a bool in the Java meaning I don't think making & anything but bitwise operator makes sense.

Huh? There have been regular discussions on the D newsgroups about bool since atleast 2001. Almost all threads about this have people arguing for the introduction of a logical (as opposed to the current numerical) bool type similar (not necessarily identical) to the Java boolean. Isn't this what we are discussing here too?

>>>> (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?
>>>
>>>
>>> I'm not against casting but implicit conversions are bad.
>> 
>> 
>> Do you mean that all implicit conversions are bad? Are the integer promotion rules bad?
> 
> Ofcourse not. But with bools yes.

I read your statement as meaning that all implicit conversions are bad. I was merely interested in why you thought so. :)

/Oskar

Oskar Linde wrote:
> && and || controls the program flow. 

If's and while's containing them control program flow (or I didn't get something right?)

> They are not algebraic operators.

They are logic operators. (Ok algebraic if we are talking about Boolean algebra).

> &,|,~,^ are real operators that also maps directly onto machine
> instructions on most cpu architectures. 

Sure they are, and I use them all the time on ints.

> Their meaning would be well defined
> for bools. 

Not really:
bool a = //somehow 2
bool b = //somehow 4
a && b == true && true == true
a & b == 0x0010 & 0x0100 == 0x0000 == false,

I mean they would work but only if true == always 1 and false == always 0.

> && and || requires branching and are therefore much less
> efficient (even though this can be optimized away in many cases). 
> 
> Also, not allowing ^ for bools would mean that code that reads a^b today
> would have to be rewritten as:
> 
> (a && !b) || (!a && b).
> 

Oops, forgot about that one, so ^ can stay :)

> 
>>>Why should &,|,^,~ not be defined
>>>and allowed for bool? It would be problematic and inconsistent not
>>>having non-short-circuit operators for booleans.
>>
>>I learned from xs0's reply that Java uses &,| for non-short-circuit
>>evaluation when arguments are of type bool. As D doesn't have a bool in
>>the Java meaning I don't think making & anything but bitwise operator
>>makes sense.
> 
> 
> Huh? There have been regular discussions on the D newsgroups about bool
> since atleast 2001. 

Tell me about it, I think it is an neverending topic for D. Maybe even if Walter got bools 'right' some people would be complaining.

> Almost all threads about this have people arguing for
> the introduction of a logical (as opposed to the current numerical) bool
> type similar (not necessarily identical) to the Java boolean. Isn't this
> what we are discussing here too?

I think so.
In the paragraf you replyed to I was just trying to say that having &,| and ^ for bools only has meaning f they are strict logic bools and not numeric.

>>>>>(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?
>>>>
>>>>
>>>>I'm not against casting but implicit conversions are bad.
>>>
>>>
>>>Do you mean that all implicit conversions are bad? Are the integer
>>>promotion rules bad?
>>
>>Ofcourse not. But with bools yes.
> 
> 
> I read your statement as meaning that all implicit conversions are bad. I
> was merely interested in why you thought so. :)

Well, I think I would be crazy to think that ;)

xs0 wrote:
> They are bitwise operations on integers, because that's what they're defined to be. We're free to define them to do something else on booleans, which I propose to be [what I said above].

Ok, now I understand what you're saying. But to have that behaviour we need very very different bools.

> 
> BTW, even Java, which has a really purist boolean implementation, uses those for exactly the stated purpose (and even calls them "logical operators", while && and || are "conditional-and" and "-or" :)
> 
> http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.5 
> 

Thanks for the link.

> 
>>> 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)
>>
>>
>> Yuck, but I would agree with it as long as conditions have to be booleans. I know it isn't a perfect world and although I would never use the above, it would still be better than what we have now (as long as all the other conditions are satisified).
> 
> I used to think so too, until I was forced to code in Java :) 

I also coded in Java and never found this to be a problem :)

> Even though I don't mind typing something as simple as
> 
> if (a!=null)
> 
> the verbosity of longer expressions really annoys the heck out of me. Now, I prefer
> 
>  > if (a && b && c && d) // check for nulls

But what is going on behind the scene if a,b,c,d are ints or ponters,
conversions to bools? I still don't get it how logic && operator can be aplied to integers. What is 5 && 3? (Except two numbers: 5,3.) It has no value regarding truth. It is neither true nor false.


>  >    ...
> 
> to
> 
>  > if (a!=null && b!=null && c!=null && d!=null)

better.... :)

>  >    ...
> 
> or D's even verboser
> 
>  > if (a !is null && b !is null && c !is null || d !is null)

the best :)

Except that little bug caused deliberately by you :)

Formated this way:

if( (a !is null) && (b !is null) && (c !is null) && (d !is null) )

it is alittle bit more clear.

Oskar Linde wrote:
> xs0 wrote:
> 
>> Don Clugston wrote:
>>
>>> 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".
>>> ...
>>> (d) Kyle
>>>
>>> Right now, (a) and (c) are the only ones which are clearly defined.
>>
>> Hmm, how about an expansion of (d):
> 
> Yes, this is very similar to the definition I have suggested. I think this is a good compromise:
> 
>> 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?
> 
> This would mean that we would keep if(a && b) and also that the type of any conditional could be defined as bool. But it would also mean that you could write bool b = 5; I guess.

Yup, but I think it's good that with

bool b=expr;
if (b) {
}

the if statement's condition always evaluates exactly the same as with

if (expr) {
}

even though the "=5" case indeed looks somewhat odd. It should be declared bad style to write that :)


>> 2) forbid casts from bool to anything else (even explicit; besides "foo?1:0" is shorter and more obvious than "cast(int)foo")
> 
> I can live with explicit cast both being allowed and not. I don't see it as an important detail. The important part is to disallow implicit casts from bool to any type.

Well, if you allow/provide a cast, it's most probably going to be to 0 and 1, which somewhat implies sort-of equivalence between 1 and true, and that's probably not a good thing.. it would mean that it'd still be possible to do arithmetics with booleans, which I believe should be avoided.


>> 4) forbid all operators on bools, except ==, !=, &&, ||, &, |, and !. (& and | don't short-circuit evaluation, but are otherwise equivalent to && and ||).
> 
> For consistency, ~ should be supported too. And ^ too of course.

Well, we have ! and != already, I'm not sure what there's to gain from having duplicates?


xs0