I am totally lost here.  I must have missed something.

What is the difference between bit and bool?

Bool is obviously not part of the D spec.

This line appears in object.d:

alias bit bool;

I keep seeing people trying to correct others by insisting that they use "bool" over "bit."

What's the deal?

Is there something wrong with representing a true/false value with a bit? It makes perfect sense to me.  And if bool is an alias for bit...?

On Mon, 9 May 2005 20:30:48 -0400, Jarrett Billingsley wrote:

> I am totally lost here.  I must have missed something.
> 
> What is the difference between bit and bool?
> 
> Bool is obviously not part of the D spec.
> 
> This line appears in object.d:
> 
> alias bit bool;
> 
> I keep seeing people trying to correct others by insisting that they use "bool" over "bit."
> 
> What's the deal?
> 
> Is there something wrong with representing a true/false value with a bit? It makes perfect sense to me.  And if bool is an alias for bit...?

Sorry, I was being a bit 'naughty'.

Conceptually, there is a difference.

But Walter has chosen to *implement* the concept of _bool_ via the _bit_ data type. This has certain advantages from the compiler writer's point of view but from a purist point of view it also allows a degree of silliness to happen. (e.g. You can do arithmetic on truth values such as "true * 3 + false" ) In practice it probably doesn't matter all that much as people are not generally going to do crazy things with truth values. However, from a readability point of view, if a coder uses bool when expressing truth values it more clearly explains their intentions. By using numeric types instead, it adds a slight fog over the coder's intentions.

So just to help people read *and* understand what you are intending by your code, one should try to be consistent and use bool for truth concepts and bit for numeric concepts (on-off) concepts. The "D" compiler doesn't care, but humans reading your code might.

It is similar to the idea that a string is a vector of characters and not really a vector of integers, even though we all know that characters are represented by specific sets of integers.

-- 
Derek
Melbourne, Australia
10/05/2005 10:30:09 AM

Jarrett Billingsley wrote:

> I am totally lost here.  I must have missed something.
> 
> What is the difference between bit and bool?

Uh-oh... "We haven't had a fight in a while" :-)

http://www.prowiki.org/wiki4d/wiki.cgi?BooleanNotEquBit

> Bool is obviously not part of the D spec.
> 
> This line appears in object.d:
> 
> alias bit bool;

Yes, and true and false are of type: const bit...
(but implemented in the compiler instead of lib)

    assert(typeid(typeof(true)) == typeid(bit));
    assert(typeid(typeof(false)) == typeid(bit));

That's how it's being done in the *current* D spec.

> I keep seeing people trying to correct others by insisting that they use "bool" over "bit."
> 
> What's the deal?

Some people are used to having a boolean type in
their language, and have some trouble going back...

And keep using the bool alias, and hoping for change ?

> Is there something wrong with representing a true/false value with a bit? It makes perfect sense to me.  And if bool is an alias for bit...? 

Not to nit-pick, but true and false are represented with "1" and "0".
They just happen to usually be stored in a bit. But sometimes in int ?

More on http://www.prowiki.org/wiki4d/wiki.cgi?BitsAndBools

--anders

Derek Parnell wrote:

> Sorry, I was being a bit 'naughty'. 

A "bool" naughty, yes ? (sorry, sorry)

> So just to help people read *and* understand what you are intending by your
> code, one should try to be consistent and use bool for truth concepts and
> bit for numeric concepts (on-off) concepts. The "D" compiler doesn't care,
> but humans reading your code might.

I've been wondering:
Does this include concepts "true" and "false" versus "0" and 1" ?
So would it be better to write, say: "assert(false);", instead ?

Another thing is that "bit" needs casts to work in numeric contexts!
I expected code like this to compile, I was using bit for a "sign":

void main()
{
  int i;
  bit sign;

  i = -1;
  sign = i >> 31;
}

But it does not:
"cannot implicitly convert expression (i >> 31) of type int to bit"

Since bit is a pseudo-boolean type, and not one of the integer ones.

> It is similar to the idea that a string is a vector of characters and not
> really a vector of integers, even though we all know that characters are
> represented by specific sets of integers.

Actually it's an array of code units, but that's another discussion...

(more on http://www.prowiki.org/wiki4d/wiki.cgi?CharsAndStrs)

--anders

On Tue, 10 May 2005 08:34:54 +0200, Anders F Björklund wrote:

> Derek Parnell wrote:
> 
>> Sorry, I was being a bit 'naughty'.
> 
> A "bool" naughty, yes ? (sorry, sorry)

LOL ... very good.

>> So just to help people read *and* understand what you are intending by your code, one should try to be consistent and use bool for truth concepts and bit for numeric concepts (on-off) concepts. The "D" compiler doesn't care, but humans reading your code might.
> 
> I've been wondering:
> Does this include concepts "true" and "false" versus "0" and 1" ?
> So would it be better to write, say: "assert(false);", instead ?

I believe so. I feel that 'assert(0)' is just as meaningful (conceptually)
as 'assert(42)', 'assert("qwerty")' or 'assert(3.1472)'.

> Another thing is that "bit" needs casts to work in numeric contexts! I expected code like this to compile, I was using bit for a "sign":
> 
> void main()
> {
>    int i;
>    bit sign;
> 
>    i = -1;
>    sign = i >> 31;
> }
> 
> But it does not:
> "cannot implicitly convert expression (i >> 31) of type int to bit"

That is because your code is trying to convert an integer (-1 >> 31) to a bit and Walter has decided that just isn't possible. You can't do implicit conversion from double to integer, either for the same reasons.

But you can implicitly convert bit to integer, just like you can do integer to double. Thus you don't always need casts to do numeric work with bits.

   int i = true * 3 + false;  // compiles with no casts.

> Since bit is a pseudo-boolean type, and not one of the integer ones.
True, not all integers are bits but all bits are integers. The bit is a subset of integers *but* with a couple of restrictions.

>> It is similar to the idea that a string is a vector of characters and not really a vector of integers, even though we all know that characters are represented by specific sets of integers.
> 
> Actually it's an array of code units, but that's another discussion...

No, conceptually its not. UTF8, UTF16, and UTF32 are vectors of code units, because these are explicit encoding (implementation) of strings. I'm talking about *strings* as a concept, not how they may or may not have been implemented by any specific programming language.

> (more on http://www.prowiki.org/wiki4d/wiki.cgi?CharsAndStrs)


-- 
Derek Parnell
Melbourne, Australia
10/05/2005 6:52:11 PM

Derek Parnell wrote:

>>"cannot implicitly convert expression (i >> 31) of type int to bit"
> 
> That is because your code is trying to convert an integer (-1 >> 31) to a
> bit and Walter has decided that just isn't possible. You can't do implicit
> conversion from double to integer, either for the same reasons.

It worked OK when I inserted a cast, but it was still surprising.

>>Actually it's an array of code units, but that's another discussion...
> 
> No, conceptually its not. UTF8, UTF16, and UTF32 are vectors of code units,
> because these are explicit encoding (implementation) of strings. I'm
> talking about *strings* as a concept, not how they may or may not have been
> implemented by any specific programming language.

Okay, then it's exactly the same as with D's booleans - I agree.

--anders

"Derek Parnell" <derek@psych.ward> wrote in message news:9mqpaqqe6nrg.1ik5gcaa5j0yv$.dlg@40tude.net...
> But Walter has chosen to *implement* the concept of _bool_ via the _bit_ data type. This has certain advantages from the compiler writer's point of view but from a purist point of view it also allows a degree of silliness to happen. (e.g. You can do arithmetic on truth values such as "true * 3 + false" )

Okay, I can see what you mean.  I don't know, I've just never thought of bits as anything other than a true/false value.. I've never really considered them as "numbers," as they can't do much besides represent a boolean value.  I suppose the ability to use bits in numeric expressions is so you can write obfuscated code, i.e.

int x=(5<y)*7;

;)

Jarrett Billingsley wrote:
> "Derek Parnell" <derek@psych.ward> wrote in message news:9mqpaqqe6nrg.1ik5gcaa5j0yv$.dlg@40tude.net...
> 
>>But Walter has chosen to *implement* the concept of _bool_ via the _bit_
>>data type. This has certain advantages from the compiler writer's point of
>>view but from a purist point of view it also allows a degree of silliness
>>to happen. (e.g. You can do arithmetic on truth values such as "true * 3 +
>>false" )
> 
> 
> Okay, I can see what you mean.  I don't know, I've just never thought of bits as anything other than a true/false value.. I've never really considered them as "numbers," as they can't do much besides represent a boolean value.  I suppose the ability to use bits in numeric expressions is so you can write obfuscated code, i.e.
> 
> int x=(5<y)*7;
> 
> ;) 
> 
> 
I think you do bit arithmetic alot in assembly, or at least your CPU does it all the time.