I think bool's are *very* important in a
language. I was very annoyed to find out
that C did not support a bool when I started
programming with it. Pascal supports bool's
and rightly so, and so do C++ and Java.

I also was very annoyed to learn that in C
(typedef'ed) bools usually take up 32 bits.
Thirty-two bits to store a True/False value!

So you can guess that I was pleased to read
that D does not only support bool's (in the
form of bit), but that it stores them in 1 bit!

However this also causes a problem, because
it is not possible to pass bits by reference,
because it is not possible to create a pointer
to a bit. So you cannot do this:


void Function (out bit bMyBit)
{
    if (whatever())
        bMyBit = true;
    else
        bMyBit = false;
}


We need good handling of boolean types.
Please do not leave it to everyone to do:

typedef ubyte bool;

and then pass the bMyBit variable as bool...

The best solution I think would be to create
a new basic type, bool, which would normally
be stored in a bit. When passed as an argument
to a function it would be converted to a byte
sized bool, so you could pass it by reference.
The byte sized bool would be implicitly
converted back to a bit size again when the
function was complete. This is possible because
a bool is guaranteed to only contain the values
0 or 1.

Is this possible? Because I know very little
of compiler technology. But this is what I would
love to see if it were possible.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

Hi,

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:abrtfd$1c9m$1@digitaldaemon.com...
> I think bool's are *very* important in a
> language.

I agree with you.

> The best solution I think would be to create
> a new basic type, bool, which would normally
> be stored in a bit.

Alternatively, references and pointers to bits could be implemented. They would be special, though. It would require a special pointer representation using an offset into a byte, or possibly a bit-mask instead. Offsets would be the best choice, I think, as they would support bit-slices better. Bit-masks would probably perform better in some situations. A downside of a special pointer representation is that it cannot be casted to anything else, so type safety needs to be enforced, and no casts should be allowed.

If performance is the primary concern (and I think it is), a byte-sized "bool" should be introduced. I don't think it should be stored in a bit, but the compiler could convert between "bool"s and "bit"s without problems. This would make "bit" the choice for arrays (bitmaps), and "bool" for almost any other purpose.

Perhaps, arrays (bitmaps) is the only reason to support "bit"s. In this case, I not sure we need "bit"s - "bool"s would be a better choice for general use (and also make the compiler simpler), and a solution to bitmaps could be provided that would extend to larger integrals. What I am advocating for, is packed arrays instead of "bit". Why should "bit" have better support than e.g. values 0..7 that also could be benefit greatly from packed arrays. However, I don't know if packed arrays should be a language feature or supported by libraries.

Regards,
Martin M. Pedersen

I agree with Martin. A byte-sized bool is the best.

However, it might be nice to auto-pack a la C's bit fields, eg.

C++:

{

    ...
    int    m_bActive    :    1;
    int    m_bAlive      :    1;

}

D:
{

    ...
    bool    m_bActive;
    bool    m_bAlive;

}

could be packed into the same byte. However, not sure whether this might lose efficiency, since when assigning from one (that is not in the zeroth position in the packed byte) a bit-shift would be required.

Overall, then, just living with the wasted 7-bits may be the bet solution, whilst perhaps allowing explicit bit fields?


"Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote in message news:abs2p2$1gem$1@digitaldaemon.com...
> Hi,
>
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:abrtfd$1c9m$1@digitaldaemon.com...
> > I think bool's are *very* important in a
> > language.
>
> I agree with you.
>
> > The best solution I think would be to create
> > a new basic type, bool, which would normally
> > be stored in a bit.
>
> Alternatively, references and pointers to bits could be implemented. They would be special, though. It would require a special pointer
representation
> using an offset into a byte, or possibly a bit-mask instead. Offsets would be the best choice, I think, as they would support bit-slices better. Bit-masks would probably perform better in some situations. A downside of
a
> special pointer representation is that it cannot be casted to anything
else,
> so type safety needs to be enforced, and no casts should be allowed.
>
> If performance is the primary concern (and I think it is), a byte-sized "bool" should be introduced. I don't think it should be stored in a bit,
but
> the compiler could convert between "bool"s and "bit"s without problems.
This
> would make "bit" the choice for arrays (bitmaps), and "bool" for almost
any
> other purpose.
>
> Perhaps, arrays (bitmaps) is the only reason to support "bit"s. In this case, I not sure we need "bit"s - "bool"s would be a better choice for general use (and also make the compiler simpler), and a solution to
bitmaps
> could be provided that would extend to larger integrals. What I am advocating for, is packed arrays instead of "bit". Why should "bit" have better support than e.g. values 0..7 that also could be benefit greatly
from
> packed arrays. However, I don't know if packed arrays should be a language feature or supported by libraries.
>
> Regards,
> Martin M. Pedersen
>
>
>

It looks like we're still in the Land of C, where bool is an integer type.

I believe "bool" should be an object having an implementation that is hidden from the user.  It would have the values "true" and "false".  The only part of the D language that would need to understand "bool" would be the logical operators.

It may be best if D's "bit" were a completely separate thing from a "bool".  A bit may be properly thought of as the smallest possible integer, and not necessarily as the keeper of the notions of true and false (though they do map conveniently).  Conversely, the implementation of "bool" is free to use a bit as its internal representation, something the user wouldn't (and shouldn't) know about anyway.  This way, D could offer a very compact implementation of, say, an array of "bool", without invoking any explicit or implicit notion of there being a bit vector or an integer involved.  Endianness wouldn't matter, since neither a single bool nor an array of bool is an integer.

With the bool implementation hidden, passing an array of bool or a single bool simply won't matter to the user.  Let the compiler handle it.  That is, if you want bits (say, for mapping to a hardware register), then use bits.  To me, single bit values in registers and multi-bit values should be treated identically, as numerical entities, unless they are explicitly converted to logical entities.  If you want boolean entities (for representing and aggregating the results of true/false tests), then use bool.  If you need to map specific numeric integer values to specific meanings, use enums, not bools.

A common weakness of C is its confusing mixing of boolean and integer operations.  For example, many standard C functions return zero to mean "no error", yet when used in a logical test, zero means "false" (no bits are "true", or set), which many users frequently confuse.  Making "bool" a completely separate thing from integers can help eliminate such confusion in D.

Of course, D will always support the messy C-way of using integers in logical tests.  If I were the (Non-) Benevolent Dictator For Life, I'd force logical operators && and || (not to be confused with the numeric parameters to magnitude comparison tests like ==, < and >=, or the bit-twiddling operations of |, &, and ^) to only work with "bool", and require explicit casts for everything else.

I recently came across code like the following:

  if (((x < 4) + (x > 0) + (x != 3))  >= 2) then { // x is sufficiently decided
}

Does this code look "just plain wrong" to anyone other than me?  If comparison operators returned "bool", and if operators such as addition and magnitude comparison were not defined for "bool", then code like the above would at least need explicit casts, making it (IMHO) much clearer.  The line above is a language hack, and is not a valid logical or mathematical expression.  It has no place in quality programming.

  int votes = 0;

  if (x<4) votes++;
  if (x > 0) votes++;
  if (x != 3) votes++;
  if (votes >= 2) then { // x is sufficiently decided }

A good C compiler would create the same object code for both forms of the expression (the first version contains an implicit temporary integer variable).  Which would you rather debug?

Remember, Boolean Algebra is part of Set Theory, and is not in any way based on integer algebra.  By definition, booleans are not integers!  They aren't even single-bit integers.  The confusion between boolean values and bits in the realm of computer programming occurred only when computers were developed that used bits (most early electronic computers were pure decimal, with binary computers following later).  And C, being the language most closely mapped to a specific computer architecture (the PDP-11), completely failed to make the distinction.  And we've been living with the consequences ever since.

Does anyone remember how to implement a multi-bit full adder with carry using only simple gates?  Gates are true boolean devices.  Treating a collection of booleans as an integer, and performing a mathematical operation upon such collections, takes some logical gymnastics.  It is non-trivial.  For good reason:  Booleans aren't integers.

If the notions of single-bit integers and boolean entities are universally and inseparably intertwined in the minds of all-programmers-who-aren't-me, then I'll take back my rant, and return quietly to my corner.


-BobC



"Martin M. Pedersen" wrote:

> Hi,
>
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:abrtfd$1c9m$1@digitaldaemon.com...
> > I think bool's are *very* important in a
> > language.
>
> I agree with you.
>
> > The best solution I think would be to create
> > a new basic type, bool, which would normally
> > be stored in a bit.
>
> ...
> Perhaps, arrays (bitmaps) is the only reason to support "bit"s. In this
> case, I not sure we need "bit"s - "bool"s would be a better choice for
> general use (and also make the compiler simpler), and a solution to bitmaps
> could be provided that would extend to larger integrals.
> ...

I think that sometimes a byte-sized (or even 32-bit sized) bool can be faster than a bit-sized bool.  That's because a store is almost universally faster than a read/modify/write operation.

However if a bit-sized bool isn't available, people use bitfields or (egad!) manual int flags fields and #define's and lots of flags &= ~(TYPE_A|TYPE_B) type gobbledygook that the compiler can deal with much easier than humans can.

So I'm glad there's a bit type, and that it packs into bytes nicely. Hopefully the compiler will try to group all the bit type variables together when possible, to save space.  Saved space means fewer cache misses, which means better performance too!

But I think it's vital to be able to deal with all types as parameters, to have pointers to them, etc.

Did anyone think having pointers to bits be extra-special pointers with a combined bit index was a good idea?  If not, why not?

Did anyone think having the compiler insert special byte or word-sized "conversion buffers" that would facilitate their use as reference parameters was a good idea?  If not, why not?

Sean

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:abrtfd$1c9m$1@digitaldaemon.com...
> I think bool's are *very* important in a
> language. I was very annoyed to find out
> that C did not support a bool when I started
> programming with it. Pascal supports bool's
> and rightly so, and so do C++ and Java.
>
> I also was very annoyed to learn that in C
> (typedef'ed) bools usually take up 32 bits.
> Thirty-two bits to store a True/False value!
>
> So you can guess that I was pleased to read
> that D does not only support bool's (in the
> form of bit), but that it stores them in 1 bit!
>
> However this also causes a problem, because
> it is not possible to pass bits by reference,
> because it is not possible to create a pointer
> to a bit. So you cannot do this:
>
>
> void Function (out bit bMyBit)
> {
>     if (whatever())
>         bMyBit = true;
>     else
>         bMyBit = false;
> }
>
>
> We need good handling of boolean types.
> Please do not leave it to everyone to do:
>
> typedef ubyte bool;
>
> and then pass the bMyBit variable as bool...
>
> The best solution I think would be to create
> a new basic type, bool, which would normally
> be stored in a bit. When passed as an argument
> to a function it would be converted to a byte
> sized bool, so you could pass it by reference.
> The byte sized bool would be implicitly
> converted back to a bit size again when the
> function was complete. This is possible because
> a bool is guaranteed to only contain the values
> 0 or 1.
>
> Is this possible? Because I know very little
> of compiler technology. But this is what I would
> love to see if it were possible.

"Matthew Wilson" <mwilson@nextgengaming.com> wrote in message news:absgk4$1r0c$1@digitaldaemon.com...
> I agree with Martin. A byte-sized bool is the best.
>
> However, it might be nice to auto-pack a la C's bit fields, eg.
>
> C++:
>
> {
>
>     ...
>     int    m_bActive    :    1;
>     int    m_bAlive      :    1;
>
> }
>
> D:
> {
>
>     ...
>     bool    m_bActive;
>     bool    m_bAlive;
>
> }

Ranged scalar types would allow the compiler to do this behind the scenes if it wanted.

> could be packed into the same byte. However, not sure whether this might lose efficiency, since when assigning from one (that is not in the zeroth position in the packed byte) a bit-shift would be required.

It would definitely lose efficiency (on all architectures I'm aware of). Not only because of the bit shift (which isn't always required) but because you can no longer just blindly write into the memory address, you have to read/modify/write to preserve other adjacent bits.   A processor that didn't have byte access would have the same problem with bytes; it'd have to use word reads/writes in combination with shifts and masking.

> Overall, then, just living with the wasted 7-bits may be the bet solution, whilst perhaps allowing explicit bit fields?

It's a fairly good solution for speed, *in some cases* (there could be cases, especially with large arrays, where due to fewer memory cache misses, it's faster to pack the bits together more)

Reliance on a size of byte isn't good because then the compiler wouldn't be able to optimize for size if the user wanted to.

I'd hate to see it go the C route and end up with a bool type that we can't rely on to be any particular size.

Sean

The only good thing I can see of having a separate bool type than bit type is that you gain the constants true and false, and the optimizer and function overloading mechanism can differentiate between them, give them subtly different behavior.  I'm not sure that's a good thing.

Surely in D, true and false are available at very least in some standard library.  If it is, I can't find it anywhere on the D website.  If not, I foresee every single programmer coming from Pascal or Java or C++ to provide conflicting declarations of enum bool { false=0, true=1 };

What happens in D when you do something like this:

enum bool { false=0, true=1 };
enum bool { false=0, true=1 };
enum bool { false=0, true=1 };

?  Is it an error?  Is it ok, since they all match?

Sean

"Robert W. Cunningham" <rcunning@acm.org> wrote in message news:3CE1EEA3.283F59E7@acm.org...
> If the notions of single-bit integers and boolean entities are universally
and
> inseparably intertwined in the minds of all-programmers-who-aren't-me,
then
> I'll take back my rant, and return quietly to my corner.

I agree.
Bool is logically :-) different from a very-small-integer, and therefore it
should be a separate type.
I would even say they should not be implicitly converted into each other.
And of course I would like to a get a pointer and/or a reference to a bool.
Absolutely.
So I think the compiler should not pack this structure, but leave it 2
separate BYTES:
struct A {
bool a, b;
};
int fn()
{
  A s;
  fn2(&s.a);
}
I can accept any implementation solution in the compiler which enables this
syntax.
It's an other question if I want to get a pointer and/or reference to a
very-small-integer, or not.
It seems consistent to have it, but impossible to provide an efficient
implementation.
Well I can live without it.

ps.: Manually typedef-ing bool sucks.

Sandor Hojtsy


"Robert W. Cunningham" <rcunning@acm.org> wrote in message news:3CE1EEA3.283F59E7@acm.org...
> It looks like we're still in the Land of C, where bool is an integer type.

> I believe "bool" should be an object having an implementation that is
hidden
> from the user.  It would have the values "true" and "false".  The only
part of
> the D language that would need to understand "bool" would be the logical operators.
[snip]
> It may be best if D's "bit" were a completely separate thing from a
"bool".  A
> bit may be properly thought of as the smallest possible integer, and not necessarily as the keeper of the notions of true and false (though they do
map
> conveniently).  Conversely, the implementation of "bool" is free to use a
bit
> as its internal representation, something the user wouldn't (and
shouldn't)
> know about anyway.  This way, D could offer a very compact implementation
of,
> say, an array of "bool", without invoking any explicit or implicit notion
of
> there being a bit vector or an integer involved.  Endianness wouldn't
matter,
> since neither a single bool nor an array of bool is an integer.
[snip]
> With the bool implementation hidden, passing an array of bool or a single
bool
> simply won't matter to the user.  Let the compiler handle it.  That is, if
you
> want bits (say, for mapping to a hardware register), then use bits.  To
me,
> single bit values in registers and multi-bit values should be treated identically, as numerical entities, unless they are explicitly converted
to
> logical entities.  If you want boolean entities (for representing and aggregating the results of true/false tests), then use bool.  If you need
to
> map specific numeric integer values to specific meanings, use enums, not
bools.
[snip]
> A common weakness of C is its confusing mixing of boolean and integer operations.  For example, many standard C functions return zero to mean
"no
> error", yet when used in a logical test, zero means "false" (no bits are "true", or set), which many users frequently confuse.  Making "bool" a completely separate thing from integers can help eliminate such confusion
in D.
[snip]
> Of course, D will always support the messy C-way of using integers in
logical
> tests.  If I were the (Non-) Benevolent Dictator For Life, I'd force
logical
> operators && and || (not to be confused with the numeric parameters to magnitude comparison tests like ==, < and >=, or the bit-twiddling
operations
> of |, &, and ^) to only work with "bool", and require explicit casts for everything else.
[snip]
> Remember, Boolean Algebra is part of Set Theory, and is not in any way
based on
> integer algebra.  By definition, booleans are not integers!  They aren't
even
> single-bit integers.  The confusion between boolean values and bits in the realm of computer programming occurred only when computers were developed
that
> used bits (most early electronic computers were pure decimal, with binary computers following later).  And C, being the language most closely mapped
to a
> specific computer architecture (the PDP-11), completely failed to make the

"Robert W. Cunningham" <rcunning@acm.org> wrote in message news:3CE1EEA3.283F59E7@acm.org...

> I recently came across code like the following:
>
>   if (((x < 4) + (x > 0) + (x != 3))  >= 2) then { // x is sufficiently
decided
> }

I write such things myself. =)
That's why C (and D) rulez!

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:abt871$2ggc$1@digitaldaemon.com...

> Surely in D, true and false are available at very least in some standard library.  If it is, I can't find it anywhere on the D website.  If not, I

true and false are language keywords. They cannot be redefined.

> What happens in D when you do something like this:
>
> enum bool { false=0, true=1 };
> enum bool { false=0, true=1 };
> enum bool { false=0, true=1 };
>
> ?  Is it an error?  Is it ok, since they all match?

I guess no. It'll give a redeclaration error.

By the way, it seems to be an interesting idea, to define bool as:

    enum bool: bit
    {
        false = 0,
        true = 1
    }

Put it somewhere in the library (maybe in some unit that's imported
automaticallly), and remove the true and false keywords from
the language... then, you will be able to cast bool to bit (and thus,
to any integer) implicitly, but an integer would require an explicit
cast to be converted to bool...