Anders F Björklund wrote:
> Walter wrote:
> ...
>> It's by choice. (Though many disagree with that choice.)
> ...
> bool as a true/false-only type, that is *not* interchangable with int.
> 
> Even if some old C/C++ users hate this, it seems to be popular with
> the new programmers growing up with new languages like C# and Java ?
> 
> --anders
> PS. I happen to like C, as I grew up on it. Just thought D was modern.

Being "modern", as in stylish, isn't an intrinsic good.  Sometimes it is, sometimes it isn't.  This time I think it would have been, but it's not my choice.

OTOH, it's certainly not too late.  You can easily define a new abstract class with two singleton subclasses, each instantiated with a global and give them appropriate mnemonic names (e.g., True and False).  This won't be a bit wide, but it's easy enough to define a mapping from bit onto (e.g.) Boolean.

The ease with which this could be done is a clear indication that it's not too late, for anyone who cares enough.  The firmness of Walter's objections indicates that it won't be a part of the standard language no matter how well you do it.

OK.  Bit arrays are much more useful than booleans.  I'm quite happy to use bit for boolean values.  (And when I do get around to writing my own logic class it will have multiple values...probably around 250 of them, excluding error states.)

Charles Hixson wrote:

> Being "modern", as in stylish, isn't an intrinsic good.  Sometimes it is, sometimes it isn't.  This time I think it would have been, but it's not my choice.

Actually I meant modern as in "high-level". integers-as-bools is so asm?

> OTOH, it's certainly not too late.  You can easily define a new abstract class with two singleton subclasses, each instantiated with a global and give them appropriate mnemonic names (e.g., True and False).  This won't be a bit wide, but it's easy enough to define a mapping from bit onto (e.g.) Boolean.

That wouldn't help much, would it ? Much happier with the "bool" alias,
even if it is not type-safe and had some problems with "out" params...

I like having my native classes around, without *having* to use Objects.

> OK.  Bit arrays are much more useful than booleans.  I'm quite happy to use bit for boolean values.  (And when I do get around to writing my own logic class it will have multiple values...probably around 250 of them, excluding error states.)

I just fail to see the combining logic behind these two statements:
(found on the D overview http://www.digitalmars.com/d/overview.html)

> Features To Drop
> #  Bit fields of arbitrary size.
>    Bit fields are a complex, inefficient feature rarely used.
and
> Bit type
>   The fundamental data type is the bit, and D has a bit data type.
>   This is most useful in creating arrays of bits:
> 	bit[] foo;

Aren't such arrays mostly used precisely to create such bit fields ?
Or do such arrays have other uses, like curing bit-operator allergies ?

Last time I messed around with 1-bit pixel maps, I just used macros:
#define BITSET(p,n)	(p)[n >> 3] |= 0x80U >> (n & 7)
#define BITCLR(p,n)	(p)[n >> 3] &= ~(0x80U >> (n & 7))
#define BITTST(p,n)	(((p)[n >> 3] & (0x80U >> (n & 7))) != 0)


Maybe it should add: "bits are also useful for emulating booleans" ? ;-)
--anders

Anders F Björklund wrote:
> Charles Hixson wrote:
> 
>> ...
> That wouldn't help much, would it ? Much happier with the "bool" alias,
> even if it is not type-safe and had some problems with "out" params...
I don't see why it wouldn't help.  I know of languages which have that singleton classes as their preferred implementation of Bool (under some name or other).  You can to the entire logic on that basis.  (Since everything False is the same False object, and everything True is the same True object.)  You would probably need a bit of syntax around things, though, as the built-in logic tests don't compare the correct way on these objects.  You could do it in several different ways, the easiest is to have a val property such that it returns the expected bit value, then one could say
  if (test.val)
  {...

> 
> I like having my native classes around, without *having* to use Objects.

But the native classes are implemented as Objects anyway, so I don't understand this.  If you mean primitive types...well, ok.  But those aren't classes any more than they are in C.
> 
>> OK.  Bit arrays are much more useful than booleans.  I'm quite happy to use bit for boolean values.  (And when I do get around to writing my own logic class it will have multiple values...probably around 250 of them, excluding error states.)
> 
> 
> I just fail to see the combining logic behind these two statements:
> (found on the D overview http://www.digitalmars.com/d/overview.html)
> 
>> Features To Drop
>> #  Bit fields of arbitrary size.
>>    Bit fields are a complex, inefficient feature rarely used.
> 
> and
> 
>> Bit type
>>   The fundamental data type is the bit, and D has a bit data type.
>>   This is most useful in creating arrays of bits:
>>     bit[] foo;
That bothers me, too.  I don't have an answer to the implied question.  But here he's talking about bit arrays of arbitrary lenght, I hope, so there will probably continue to be bit arrays.  I hope of arbitrary length.  (The statement could mean that isolated bit variables won't be packed in a structure.  I hope.)
> 
> 
> Aren't such arrays mostly used precisely to create such bit fields ?
Actually, I usually use bit arrays as arrays of logical values.  I don't know how others use them, but I suspect it depends on what they are doing.

> Or do such arrays have other uses, like curing bit-operator allergies ?
> 
> Last time I messed around with 1-bit pixel maps, I just used macros:
> #define BITSET(p,n)    (p)[n >> 3] |= 0x80U >> (n & 7)
> #define BITCLR(p,n)    (p)[n >> 3] &= ~(0x80U >> (n & 7))
> #define BITTST(p,n)    (((p)[n >> 3] & (0x80U >> (n & 7))) != 0)
> 
> 
> Maybe it should add: "bits are also useful for emulating booleans" ? ;-)
> --anders

Charles Hixson wrote:

>> I like having my native classes around, without *having* to use Objects.
> 
> But the native classes are implemented as Objects anyway, so I don't understand this.  If you mean primitive types...well, ok.  But those aren't classes any more than they are in C.

I meant primitive types, sorry. I love that bool and string are not
full-blown objects but built-in. And would like to keep it that way.

There could be full "Boolean" and "String" classes too.. Like in Java ?
Naturally with full auto-boxing and -unboxing, like in C# and JDK 1.5:

   int i = 1;
   Integer o = i;        // boxing
   int j = cast(int) o;  // unboxing

(Google said: http://www.dotnetextreme.com/articles/cSharpBoxing.asp,
also http://java.sun.com/developer/technicalArticles/releases/j2se15)

D already has the same (truly awesome!) capability with properties:
http://www.digitalmars.com/d/cpptod.html#properties

> That bothers me, too.  I don't have an answer to the implied question.  But here he's talking about bit arrays of arbitrary lenght, I hope, so there will probably continue to be bit arrays.  I hope of arbitrary length.  (The statement could mean that isolated bit variables won't be packed in a structure.  I hope.)

I can see that bit[] is a useful language construct, just as char[] is.
Just don't think that it should have boolean semantics, but be integers?

They are equally pesky to map to bytes, since a bit is 0.125 bytes wide
and a char is 1, 2, 3, or 4 bytes wide depending on "how Unicode" it is.

As I understand it, an array is stored as a length / byte pointer duple?
But I haven't verified this in DMD source code, when it comes to bit[].

> Actually, I usually use bit arrays as arrays of logical values.  I don't know how others use them, but I suspect it depends on what they are doing.

Sounds like bool[] would be more natural for storing a bunch of booleans, just like bit[] could be useful for storing bitmaps ?

--anders

In article <ckmtds$am9$1@digitaldaemon.com>, Charles Hixson says...
>...You can easily define a new abstract class with two singleton subclasses, each instantiated with a global and give them appropriate mnemonic names (e.g., True and False).  This won't be a bit wide, but it's easy enough to define a mapping from bit onto (e.g.) Boolean.


All this is completely missing the valid points brought up by Anders Bjoerklund, that for type safety, all conditional statements should require a boolean expression.  As far as I know, the only way to attain type safety is to implement it as part of the language definition.

Anders pointed out 4 types of conditional statements that he hoped would be illegal for type-safety reasons.  Ilya Minkov pointed out that one of these statements was illegal not for type reasons, but because assignment was forbidden.  That leaves three.  In my message of Oct. 7 I gave examples of errors that are difficult for a programmer to spot, but trivial for a compiler. On Oct. 11 I pointed out that the meaning of a conditional statement depends greatly on the data type, whereas this is not true if a boolean expression is required.  I would be happy to be proven wrong on these points, but so far no one has attempted a rebuttal.

I suppose the discussion centered on the libraries is an attempt to make the best of the situation without changing the language.  But has Walter not already done that?  It seems to me that his bool type is about as good as it can be for a type implemented in a library.

It's just that I don't see how libraries can possibly achieve type safety.  I cannot understand any reason for defining a basic type in a library.  In the case of C++, I think it was done as a half-hearted measure because once the language was set in stone, there was no good way to do it.  D is about to be set in stone, if it has not been already.

As far as I know, no one has pointed out a single disadvantage to type checking conditional statements, and we certainly know of several major disadvantages.  D is disadvantaged in this respect to Java, C#, FORTRAN (since at least 1977), all Pascal-family languages, and probably quite a few others.

Some view these messages as a war.  I would not continue with this message if I were convinced the points were either understood, except by a few, or refuted. I'm not sure the point has gotten across.  Somebody please tell me I'm wrong.

I'm sorry, when I wrote the previous message I had not noticed the thread entitled "Bits again.  A proposal."  I notice that my remarks are somewhat parallel to some of the comments in the other thread.

Still, somehow, the conversations always seem to come back to arguments about bits used as booleans.  Here's an oddity in the computer world:  FORTRAN has at least two type-compatible boolean types -- 1 byte and 4 bytes.  Maybe 8 bytes too--I forget.  I don't think it matters much how booleans are defined, as long as they are part of the language and they are called "boolean", "logical", or "bool".

In article <ckor2s$2586$1@digitaldaemon.com>, Rex Couture says...
>
>In article <ckmtds$am9$1@digitaldaemon.com>, Charles Hixson says...
>>...You can easily define a new abstract class with two singleton subclasses, each instantiated with a global and give them appropriate mnemonic names (e.g., True and False).  This won't be a bit wide, but it's easy enough to define a mapping from bit onto (e.g.) Boolean.
>
>
>All this is completely missing the valid points brought up by Anders Bjoerklund, that for type safety, all conditional statements should require a boolean expression.  As far as I know, the only way to attain type safety is to implement it as part of the language definition.
>
>Anders pointed out 4 types of conditional statements that he hoped would be illegal for type-safety reasons.  Ilya Minkov pointed out that one of these statements was illegal not for type reasons, but because assignment was forbidden.  That leaves three.  In my message of Oct. 7 I gave examples of errors that are difficult for a programmer to spot, but trivial for a compiler. On Oct. 11 I pointed out that the meaning of a conditional statement depends greatly on the data type, whereas this is not true if a boolean expression is required.  I would be happy to be proven wrong on these points, but so far no one has attempted a rebuttal.
>
>I suppose the discussion centered on the libraries is an attempt to make the best of the situation without changing the language.  But has Walter not already done that?  It seems to me that his bool type is about as good as it can be for a type implemented in a library.
>
>It's just that I don't see how libraries can possibly achieve type safety.  I cannot understand any reason for defining a basic type in a library.  In the case of C++, I think it was done as a half-hearted measure because once the language was set in stone, there was no good way to do it.  D is about to be set in stone, if it has not been already.
>
>As far as I know, no one has pointed out a single disadvantage to type checking conditional statements, and we certainly know of several major disadvantages.  D is disadvantaged in this respect to Java, C#, FORTRAN (since at least 1977), all Pascal-family languages, and probably quite a few others.
>
>Some view these messages as a war.  I would not continue with this message if I were convinced the points were either understood, except by a few, or refuted. I'm not sure the point has gotten across.  Somebody please tell me I'm wrong.
>
>

Can anyone refer us back to something by Walter on this issue with meat in it? i.e., not just "that's the way it is", or "I'm carrying forward this from  C".

Rex Couture wrote:

> Still, somehow, the conversations always seem to come back to arguments about
> bits used as booleans.  Here's an oddity in the computer world:  FORTRAN has at
> least two type-compatible boolean types -- 1 byte and 4 bytes.  Maybe 8 bytes
> too--I forget.  I don't think it matters much how booleans are defined, as long
> as they are part of the language and they are called "boolean", "logical", or
> "bool".

For reasons of naming compatibility with C99 and C++,
I strongly suggest using the name "bool" for the type.
(matches "int" for integer, and "char" for character)

This (alias) is already in object.d,
so the name "bool" should be settled...
The underlying type, however, is broken.

--anders

larrycowan wrote:
> In article <ckor2s$2586$1@digitaldaemon.com>, Rex Couture says...
> 
>>In article <ckmtds$am9$1@digitaldaemon.com>, Charles Hixson says...
>>
>>>...You can easily define a new abstract class with two singleton subclasses, each instantiated with a global and give them appropriate mnemonic names (e.g., True and False).  This won't be a bit wide, but it's easy enough to define a mapping from bit onto (e.g.) Boolean.
>>
>>
>>All this is completely missing the valid points brought up by Anders Bjoerklund,
>>that for type safety, all conditional statements should require a boolean
>>expression.  As far as I know, the only way to attain type safety is to
>>implement it as part of the language definition.
>>
>>Anders pointed out 4 types of conditional statements that he hoped would be
>>illegal for type-safety reasons.  Ilya Minkov pointed out that one of these
>>statements was illegal not for type reasons, but because assignment was
>>forbidden.  That leaves three.  In my message of Oct. 7 I gave examples of
>>errors that are difficult for a programmer to spot, but trivial for a compiler.
>>On Oct. 11 I pointed out that the meaning of a conditional statement depends
>>greatly on the data type, whereas this is not true if a boolean expression is
>>required.  I would be happy to be proven wrong on these points, but so far no
>>one has attempted a rebuttal.
>>
>>I suppose the discussion centered on the libraries is an attempt to make the
>>best of the situation without changing the language.  But has Walter not already
>>done that?  It seems to me that his bool type is about as good as it can be for
>>a type implemented in a library.
>>
>>It's just that I don't see how libraries can possibly achieve type safety.  I
>>cannot understand any reason for defining a basic type in a library.  In the
>>case of C++, I think it was done as a half-hearted measure because once the
>>language was set in stone, there was no good way to do it.  D is about to be set
>>in stone, if it has not been already.
>>
>>As far as I know, no one has pointed out a single disadvantage to type checking
>>conditional statements, and we certainly know of several major disadvantages.  D
>>is disadvantaged in this respect to Java, C#, FORTRAN (since at least 1977), all
>>Pascal-family languages, and probably quite a few others.
>>
>>Some view these messages as a war.  I would not continue with this message if I
>>were convinced the points were either understood, except by a few, or refuted.
>>I'm not sure the point has gotten across.  Somebody please tell me I'm wrong.
>>
>>
> 
> 
> Can anyone refer us back to something by Walter on this issue with meat in it?
> i.e., not just "that's the way it is", or "I'm carrying forward this from  C".

Walter doesn't seem to see any big problems with the bit situation, so he hasn't said much on the issue. A lot of people have said a lot of things on the issue, but I haven't seen any consensus develop.

In any case, I've found some of Walter's best posts on bit vs. bool and wiki-ized them: http://www.prowiki.org/wiki4d/wiki.cgi?BooleanNotEquBit/PostsByWalter

Enjoy!

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

In article <ckpkqj$2sa3$1@digitaldaemon.com>, J C Calvarese says...
>In any case, I've found some of Walter's best posts on bit vs. bool and wiki-ized them: http://www.prowiki.org/wiki4d/wiki.cgi?BooleanNotEquBit/PostsByWalter

Thanks for collecting those messages.  I think most of us have read them before. Unfortunately, I don't see that they address any of the issues we are discussing.