www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Too late for boolean ?

reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Is it too late to hope for D to get a *real* boolean type ?

That is, not the integer-compatible bit one that is "bool";
but a special-purpose "boolean" type, like the one Java has.



I was hoping for the following code snippets to be illegal:

if (pointer)
if (a = b) // just a typo!
if (c = readchar())
i = true + 1;

Instead they could be replaced by the equivalent new code:

if (pointer != null)
if (a == b) // what was meant!
if ((c = readchar()) != 0)
i = (true ? 1 : 0) + 1;




It seems like "true" and "false" has already been defined
as "bit", which I think is unfortunate. They should have
been "boolean". Better bit names would be "on" and "off".

Can it be added/changed, or are we stuck with C9X/C++ bool?

--anders


PS.
Aliasing "bit" to represent "bool" is perfectly fair.
It's even *better* than what my current GCC 3.4 does,
where sizeof(bool) == 4 ! (I'm guessing it uses "int")

Just that I had hoped for something that was better...
(since C source code compatibility is not an issue ?)
Or did Walter actively CHOOSE the old C style, for D ?
Oct 06 2004
next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Anders F Bj=F6rklund schrieb:

 Is it too late to hope for D to get a *real* boolean type ?



 I was hoping for the following code snippets to be illegal:
=20
 if (pointer)


Why should that be illegal? I find it very elegant at many cases. Many=20
others also do.


 if (a =3D b) // just a typo!


Assignment in if statement is made illegal and will be rejected by the=20
compiler.


 Instead they could be replaced by the equivalent new code:



 i =3D (true ? 1 : 0) + 1;


I don't see a reason why this here should be done.


 Can it be added/changed, or are we stuck with C9X/C++ bool?


In principle, it is not like anything couldn't be changed by a technical =

reason, we're not past 1.0 yet. However, such questions have already=20
been discussed dozens, dozens of times with no consensus. Your message=20
doesn't contribute much to the discussion because it fails to provide=20
any argument as to why we should do that. The common typo you show is=20
detected by the compiler. You didn't even check the code you post.

-eye
Oct 06 2004
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ilya Minkov wrote:


 Why should that be illegal? I find it very elegant at many cases. Many 
 others also do.


Because the type of variable "pointer" is not a boolean ?

This was after adding a new boolean core type to the language,
and then requiring that if(), while() etc. get boolean params.


 if (a = b) // just a typo!


 
 Assignment in if statement is made illegal and will be rejected by the 
 compiler.


Great! (gcc catches it too, at least it issues a warning with -Wall:
"warning: suggest parentheses around assignment used as truth value")


 i = (true ? 1 : 0) + 1;


 
 I don't see a reason why this here should be done.


Again, because "boolean" and "int" are different types ?
(pros and cons have been discussed before, won't reiterate)


 i = true + 1;




In C9X and C++, they both assign a value 2 to the i variable.



 In principle, it is not like anything couldn't be changed by a technical 
 reason, we're not past 1.0 yet. However, such questions have already 
 been discussed dozens, dozens of times with no consensus. Your message 
 doesn't contribute much to the discussion because it fails to provide 
 any argument as to why we should do that. The common typo you show is 
 detected by the compiler. You didn't even check the code you post.


I compiled the code now, and it did say:
'=' does not give a boolean result


I just wanted to point out that C(9X) and C++ chose one solution,

C side, just wanted to know if that was by choice or by accident ?

If there are no plans to add such a non-arithmetic type to D,
then I'm perfectly fine with the current ones: bit, 1 and 0 -
and their aliases: bool, true and false. I'm an old C user too.


I just thought that like strings and garbage collection, "boolean"
was a nice addition to C by Java, and hoped it would end up in D too...

But if C and C++ have gotten along without it, so could D, I guess ?
Just didn't see any strong statements that D would not ever add one...


Sorry for beating the poor old horse,
--anders
Oct 06 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:ck1joc$4bl$1 digitaldaemon.com...

 I just wanted to point out that C(9X) and C++ chose one solution,

 C side, just wanted to know if that was by choice or by accident ?


It's by choice. (Though many disagree with that choice.)
Oct 11 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:


I just wanted to point out that C(9X) and C++ chose one solution,

C side, just wanted to know if that was by choice or by accident ?


 
 It's by choice. (Though many disagree with that choice.)


It's just seem like a BACKWARD choice, considering what others did ?


Among all the other modernizations like: obsoleting pointers,
changing header files into modules, garbage collected memory,
removing the need to sometimes use "->" instead of just ".";

we find an ancient C usage like "no boolean" ? Not even the C++ "bool".


I think it is great that we have moved forward to C99 and introduced
the alias "bool" for the preferred integer type for storing booleans.
Even better would be if bool became a reserved and built-in *keyword*


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


--anders


PS. I happen to like C, as I grew up on it. Just thought D was modern.
Oct 11 2004
next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
Anders F Björklund wrote:


 Walter wrote:
 

I just wanted to point out that C(9X) and C++ chose one solution,

C side, just wanted to know if that was by choice or by accident ?


 
 It's by choice. (Though many disagree with that choice.)


 
 It's just seem like a BACKWARD choice, considering what others did ?


Seems like a fine choice to me. I have no problem with it.


 
 Among all the other modernizations like: obsoleting pointers,
 changing header files into modules, garbage collected memory,
 removing the need to sometimes use "->" instead of just ".";
 
 we find an ancient C usage like "no boolean" ? Not even the C++ "bool".


The C++ bool type and the D bit type are very similiar. Are you saying D
doesn't have the equivalent to C++'s bool? Or are you saying that C++'s
bool is not a true boolean type?


 
 I think it is great that we have moved forward to C99 and introduced
 the alias "bool" for the preferred integer type for storing booleans.
 Even better would be if bool became a reserved and built-in *keyword*

 
 bool as a true/false-only type, that is *not* interchangable with int.


I think I've heard this before... hmm... let me search the newsgroup...

Seriously, though, I'm pretty shocked people consider bit/bool such a big
deal. I'm more concerned about the state of D's libraries and tools.


 
 Even if some old C/C++ users hate this, it seems to be popular with

 
 --anders
 
 
 PS. I happen to like C, as I grew up on it. Just thought D was modern.
Oct 11 2004
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Ben Hinkle wrote:


It's just seem like a BACKWARD choice, considering what others did ?


 
 Seems like a fine choice to me. I have no problem with it.


I can live with it too, if nothing else just to stop this "war" !

I know that "Arcane Jill" came to the same conclusion earlier:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/2973



we find an ancient C usage like "no boolean" ? Not even the C++ "bool".


 
 The C++ bool type and the D bit type are very similiar. Are you saying D
 doesn't have the equivalent to C++'s bool? Or are you saying that C++'s
 bool is not a true boolean type?


C++ has a bool type which can be implicitly converted to integer.
D has an integer type called "bit". There is a difference here...
(even if Walter likes to think that it's all aspects of the Tao)


The current state in D is more similar to C99, which has <stdbool.h>
It defines "bool" as a macro for _Bool (similar to D's choice of bit),
and also defines the constants "true" and "false" as the values 1 and 0.

I just wanted a new D keyword "bool", which would be *equal* to bit.
(preferrably "bit" should only accept 0/1 and "bool" only false/true,
but since they are implicitly converted it doesn't make a difference)

* So I am saying that D does not (yet?) have the equivalent of C++ bool.



and have all conditionals *require* this type or throw a "type error".
But that new feature can wait for "D 2.0", since it's so controversial.

One could even consider a half-way "bool" type that is not *implicitly*
converted, but still can be explicitly converted by the use of a cast ?
Like most compromises, that "mule" of a bool is neither horse or donkey.

* So I am also definitely saying that C++'s bool is not a true boolean.


I have no issue whatsoever with the choice of "bit" to represent a bool,
I think it makes much more sense than using "char" or "int" like C does.
But if true and false are D keywords, then I think bool should be too ?
(Or go back to the dark ages of C99 and remove keywords true and false
too: "alias bit bool; const bit true = 1; const bit false = 0;". Horror)
That's my main point: the current selection of keywords is inconsistent!

My rather simple Request For Enhancement was a new D keyword: "bool".
(AND to make true and false have this type, which is synonym to bit)
NOT to make this type-safe or anything, as that is a *separate* RFE...
If that is rejected, I suggest introducing a new stdbool.d like above.
(i.e. remove keywords true and false, and just have bits: like 0 and 1)
I would vastly prefer the first, but the second is better than current.

* Having a C++ "bool" type seems like a good COMPROMISE for D to take ?




 Seriously, though, I'm pretty shocked people consider bit/bool such a big
 deal. I'm more concerned about the state of D's libraries and tools.


People are funny that way. The sad part is that it is just hindering D,


I actually think more people are scared off by this war itself, than by
D having or not having a boolean type ? Arguments are just so tiring...


Just hoped "we" could move further on the evolutionary scale before 1.0:


                             ^
                         D is here

Or, wait, Boolean Darwinism is just another religion too - right ? :-P

--anders


PS.
    "The following sentence is true.
     The preceding sentence is false."
     -- from Zen and the Art of Boolean
Oct 12 2004
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:ckgbj4$bjg$1 digitaldaemon.com...

 Ben Hinkle wrote:


It's just seem like a BACKWARD choice, considering what others did ?


 Seems like a fine choice to me. I have no problem with it.


 I can live with it too, if nothing else just to stop this "war" !

 I know that "Arcane Jill" came to the same conclusion earlier:
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/2973


then why the shouting? (typing BACKWARD in all caps is the way one "shouts"
in newsgroups and email)


we find an ancient C usage like "no boolean" ? Not even the C++ "bool".


 The C++ bool type and the D bit type are very similiar. Are you saying D
 doesn't have the equivalent to C++'s bool? Or are you saying that C++'s
 bool is not a true boolean type?


 C++ has a bool type which can be implicitly converted to integer.
 D has an integer type called "bit". There is a difference here...
 (even if Walter likes to think that it's all aspects of the Tao)


You say "tom-a-to". I say "tom-ah-to". (or maybe I should say "nuclear" and
"nucular"). The differences are minor IMO.


 The current state in D is more similar to C99, which has <stdbool.h>
 It defines "bool" as a macro for _Bool (similar to D's choice of bit),
 and also defines the constants "true" and "false" as the values 1 and 0.

 I just wanted a new D keyword "bool", which would be *equal* to bit.
 (preferrably "bit" should only accept 0/1 and "bool" only false/true,
 but since they are implicitly converted it doesn't make a difference)

 * So I am saying that D does not (yet?) have the equivalent of C++ bool.


Sure it doesn't have the exact same C++ semantics but then C++ doesn't have
the D data type called "bit".



 and have all conditionals *require* this type or throw a "type error".
 But that new feature can wait for "D 2.0", since it's so controversial.


though the more time passes the less likely bool will change.


 One could even consider a half-way "bool" type that is not *implicitly*
 converted, but still can be explicitly converted by the use of a cast ?
 Like most compromises, that "mule" of a bool is neither horse or donkey.

 * So I am also definitely saying that C++'s bool is not a true boolean.


ok.


 I have no issue whatsoever with the choice of "bit" to represent a bool,
 I think it makes much more sense than using "char" or "int" like C does.
 But if true and false are D keywords, then I think bool should be too ?
 (Or go back to the dark ages of C99 and remove keywords true and false
 too: "alias bit bool; const bit true = 1; const bit false = 0;". Horror)
 That's my main point: the current selection of keywords is inconsistent!


Consistency sounds like a good thing. I can buy the argument that either
bool should be a keyword or true/false should not. And actually I'd lean
towards defining true/false in object.d right next to the bool alias as you
suggest. If someone really really really wants to redefine bool they should
be able to redefine true and false.


 My rather simple Request For Enhancement was a new D keyword: "bool".
 (AND to make true and false have this type, which is synonym to bit)
 NOT to make this type-safe or anything, as that is a *separate* RFE...
 If that is rejected, I suggest introducing a new stdbool.d like above.
 (i.e. remove keywords true and false, and just have bits: like 0 and 1)
 I would vastly prefer the first, but the second is better than current.

 * Having a C++ "bool" type seems like a good COMPROMISE for D to take ?



ok


 Seriously, though, I'm pretty shocked people consider bit/bool such a




big

 deal. I'm more concerned about the state of D's libraries and tools.


 People are funny that way. The sad part is that it is just hindering D,



I doubt bit/bool is hindering D.


 I actually think more people are scared off by this war itself, than by
 D having or not having a boolean type ? Arguments are just so tiring...


yup.


 Just hoped "we" could move further on the evolutionary scale before 1.0:


                              ^
                          D is here

 Or, wait, Boolean Darwinism is just another religion too - right ? :-P

 --anders


 PS.
     "The following sentence is true.
      The preceding sentence is false."
      -- from Zen and the Art of Boolean
Oct 12 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:


It's just seem like a BACKWARD choice, considering what others did ?




I can live with it too, if nothing else just to stop this "war" !


 
 then why the shouting? (typing BACKWARD in all caps is the way one "shouts"
 in newsgroups and email)


I know, I know. Sorry about that... Feel better now.


 Consistency sounds like a good thing. I can buy the argument that either
 bool should be a keyword or true/false should not. And actually I'd lean
 towards defining true/false in object.d right next to the bool alias as you
 suggest. If someone really really really wants to redefine bool they should
 be able to redefine true and false.


Either/or, I think ?

A good name for the module would be stdbool.d,
since that would make it similar to stdint.d ?

module std.stdbool;
alias bit bool;
const bool true = 1;
const bool false = 0;

But I would rather have a "bool" keyword like C++.
Even if it is still just an alias for the bit type.


* Having a C++ "bool" type seems like a good COMPROMISE for D to take ?





Oops, shouted again. Time for some therapy, perhaps ?

--anders
Oct 12 2004
parent Sean Kelly <sean f4.ca> writes:
In article <ckgt5r$sp4$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

But I would rather have a "bool" keyword like C++.
Even if it is still just an alias for the bit type.


The way I see it, there are two options for D.  Either we stick with packed bit
values in arrays and D stays pretty much the way it is (maybe even toss the
"bool" alias... renaming true/false to on/off has merit but I think would be
unnecessarily confusing), or we do away with packed bit values and change the
"bit" keyword to "bool."  I don't feel that middle ground is appropriate as bool
and bit aren't strictly the same thing--one has a physical component while the
other is entirely logical.  I avoid using "bool" in my D code for exactly this
reason--I feel it's misleading.

All ideologies aside, I do think that "bit" is consistent with the trend towards
fixed-size types in D.  My only personal concern is with packed bit behavior,
but I haven't made up my mind whether I like it or not.  Are the slicing
requirements acceptable?  Should any attempt be made to enable slicing at all?
What about addressing?  These are all issues that come up with vector<bool> in
C++, but I've found that overload to be more convenient than problematic.
Still, I find myself wanting to be able to do things like this:

bit[8] a, b;

a[0] = 1;
b[0] = 1;

bit[] c = a + b;

What should the result be: an array with all bits zero, or an array with c[1] ==
1?  In a sense I would expect the latter result, though this would be
inconsistent with how vector operations would likely behave for other types, and
it seems an unreasonable expectation to put on the compiler.  Plus, the effect
can already be achieved this way:

byte c = cast(byte)*&a[0] + cast(byte)*&b[0];

I really can't decide whether this unique storage property of bit values will
turn out to be more of a help or a hindrance as time goes on.  It's not
something that's ever bothered me personally, either in D or in C++, but I still
haven't decided how I feel about this from an idealistic perspective.


Sean
Oct 12 2004
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
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

 
 --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.)
Oct 14 2004
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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 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
Oct 14 2004
parent reply Charles Hixson <charleshixsn earthlink.net> writes:
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 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
Oct 14 2004
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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 ?


    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
Oct 15 2004
prev sibling parent reply Rex Couture <Rex_member pathlink.com> writes:
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

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.
Oct 15 2004
next sibling parent reply Rex Couture <Rex_member pathlink.com> writes:
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".
Oct 15 2004
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Oct 15 2004
prev sibling parent reply larrycowan <larrycowan_member pathlink.com> writes:
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

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".
Oct 15 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
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

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/
Oct 15 2004
next sibling parent Rex Couture <Rex_member pathlink.com> writes:
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.
Oct 15 2004
prev sibling parent larrycowan <larrycowan_member pathlink.com> writes:
In article <ckpkqj$2sa3$1 digitaldaemon.com>, J C Calvarese says...

larrycowan wrote:

 In article <ckor2s$2586$1 digitaldaemon.com>, Rex Couture says...
 

In article <ckmtds$am9$1 digitaldaemon.com>, Charles Hixson says...


 
 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/


Thanks.  So we have bools as 0:!0, and 0:1 bit arrays to store them but "
'='does not give a boolean result " and he's hanging tight on all fronts - some
I would side with and some not, but it is not going to move.  We can get onto
more productive discussions.

The wiki4d is a great place to have faq stuff and this needed to be there.
Again, thanks.
Oct 15 2004
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 06 Oct 2004 21:46:40 +0200, Ilya Minkov wrote:


 Anders F Björklund schrieb:

 Is it too late to hope for D to get a *real* boolean type ?


 

 I was hoping for the following code snippets to be illegal:
 
 if (pointer)


 
 Why should that be illegal? I find it very elegant at many cases. Many 
 others also do.


This syntax is just a shorthand for 'if (pointer != null)', but in
conceptual terms the 'if' statement syntax should be more like ...

  IFSTMT :: 'if' '(' boolean_expression ')' statement_block [ 'else'
statement_block ]

In other words, the expression within the parenthesis should result in a
boolean data value. 

I take the following to be true even if C/C++/D et al disagree somewhat:
 ** Pointers are not booleans. 
 ** Numbers are not booleans. 
 ** Booleans are not numbers.


 if (a = b) // just a typo!


 
 Assignment in if statement is made illegal and will be rejected by the 
 compiler.


It is odd maybe, that D decides to make this 'concession' but leaves other
potential bug makers in place (eg fallthru in switch)


 Instead they could be replaced by the equivalent new code:


 

 i = (true ? 1 : 0) + 1;


 
 I don't see a reason why this here should be done.


Simple, booleans are not numbers so therefore one cannot do arithmetic on
them. What do three truths and a falsehood add up to? It makes no sense
does it? What one needs to do is to say, if we substitute each truth with 1
and each falsehood with 0, then 3*T + F = 3. The syntax above makes it
clear to the reader of the code that such an arbitary substitution is being
carried out. I say 'arbitary' because some systems believe that a truth
should be substituted by -1.


 Can it be added/changed, or are we stuck with C9X/C++ bool?


 
 In principle, it is not like anything couldn't be changed by a technical 
 reason, we're not past 1.0 yet. However, such questions have already 
 been discussed dozens, dozens of times with no consensus. Your message 
 doesn't contribute much to the discussion because it fails to provide 
 any argument as to why we should do that. The common typo you show is 
 detected by the compiler. You didn't even check the code you post.
 
 -eye


I hope I've help to provide an "argument as to why we should do that".

-- 
Derek
Melbourne, Australia
7/10/2004 9:48:43 AM
Oct 06 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:

 I take the following to be true even if C/C++/D et al disagree somewhat:
  ** Pointers are not booleans. 
  ** Numbers are not booleans. 
  ** Booleans are not numbers.


Actually, they all agree on: "there is no boolean"

"true" is a number, with the value 1.
"false" is a number, with the value 0.

"equals true" is the same as "is not zero"
"equals false" is the same as "equals zero".

And the recommended int type for storing is "bool".

--andeers
Oct 07 2004
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 07 Oct 2004 13:51:32 +0200, Anders F Björklund wrote:


 Derek Parnell wrote:

 I take the following to be true even if C/C++/D et al disagree somewhat:
  ** Pointers are not booleans. 
  ** Numbers are not booleans. 
  ** Booleans are not numbers.


 
 Actually, they all agree on: "there is no boolean"
 
 "true" is a number, with the value 1.
 "false" is a number, with the value 0.
 
 "equals true" is the same as "is not zero"
 "equals false" is the same as "equals zero".
 
 And the recommended int type for storing is "bool".


I assume your comments above are saying "This is how C sees it..." rather
than "This is how it is in the world...", because truth is *not* 1 and
falsehood is *not* 0. The designers of C decided to use 1 to represent
truth and 0 to represent falsehood. Actually, as you say above, depending
on circumstances any non-zero number can be used to represent truth in a C
program. But that does not make Truth and Falsehood to be intrinsically
numeric. 

-- 
Derek
Melbourne, Australia
8/10/2004 9:14:22 AM
Oct 07 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:

I take the following to be true even if C/C++/D et al disagree somewhat:


Actually, they all agree on: "there is no boolean"


 I assume your comments above are saying "This is how C sees it..." rather
 than "This is how it is in the world...", because truth is *not* 1 and
 falsehood is *not* 0. The designers of C decided to use 1 to represent
 truth and 0 to represent falsehood. Actually, as you say above, depending
 on circumstances any non-zero number can be used to represent truth in a C
 program. But that does not make Truth and Falsehood to be intrinsically
 numeric. 


I was just talking about those three languages: C(9X), C++, and now D.
In all three of those, "true" is a constant number 1 and "false" is a 0

In other languages, such as Forth, true is defined as -1 (=all bits on)
Size of "bool" varies, but usually: 1 bit,8 bits (char),or 32 bits (int)


I was *all for* introducing a proper boolean class, non-arithmethic...
And then make all conditionals require and comparisons return this type.
Just like the way that it works in Java, see that language for examples.

But it seems like D prefers to handle logic "numerically", like C/C++ ?
In D, you use the inttype "bit" and the values "1" and "0" for booleans.
Or use their aliases: "bool", "true", "false" but that's just aesthetic


Another way of putting it:
Q. Too late for boolean ?
A. Yes.

--anders
Oct 07 2004
next sibling parent Derek Parnell <derek psych.ward> writes:
On Fri, 08 Oct 2004 02:28:34 +0200, Anders F Björklund wrote:

[snip]


 Another way of putting it:
 Q. Too late for boolean ?
 A. Yes.


Sadly, I suspect you are correct with that summary.

I think that while Walter has ultimate control over the D specification
that a true (text-book) boolean data type will never surface. Eventually,
when /bool/ does arrive as an intrinsic type, they will be too afraid of
breaking existing code to disallow arithmetic operations on it. So yes, the
horse has bolted and shutting-the-gate time has already passed us by.

-- 
Derek
Melbourne, Australia
8/10/2004 10:36:16 AM
Oct 07 2004
prev sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <ck4n04$d4p$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

Another way of putting it:
Q. Too late for boolean ?
A. Yes.


I prophesize the opposite. True - for so long as Walter controls the spec, we
are unlikely to have a boolean bool. However, if D is successful (as we hope it
will be) then the time will come when standards committees such as ISO and the
like will take over the spec. At that time, bool will be added. It's a bummer
that we probably won't see it before then, but that's how it is.

Jill

PS. Here at the Church of Typesafety, we also hold as dogma and eternal truth
that **a character is not a number; a character is not a boolean; and a
character is not a pointer**. I seem to be alone in that opinion, however, so
I'll shut up before another thread spawns.
Oct 07 2004
next sibling parent Derek Parnell <derek psych.ward> writes:
On Fri, 8 Oct 2004 06:33:57 +0000 (UTC), Arcane Jill wrote:


 In article <ck4n04$d4p$1 digitaldaemon.com>,
 =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

Another way of putting it:
Q. Too late for boolean ?
A. Yes.


 
 I prophesize the opposite. True - for so long as Walter controls the spec, we
 are unlikely to have a boolean bool. However, if D is successful (as we hope it
 will be) then the time will come when standards committees such as ISO and the
 like will take over the spec. At that time, bool will be added. It's a bummer
 that we probably won't see it before then, but that's how it is.
 
 Jill
 
 PS. Here at the Church of Typesafety, we also hold as dogma and eternal truth
 that **a character is not a number; a character is not a boolean; and a
 character is not a pointer**. I seem to be alone in that opinion, however, so
 I'll shut up before another thread spawns.


Well not /so/ alone. I believe as you do re characters. Computer systems
use numbers to represent characters, but that is only a representation and
not the character itself. 

So maybe UniCode can be seen as one (of many) protocols that represent
characters using numbers. And utf8, utf16, utf32, etc... are various
implementations of that protocol. 

-- 
Derek
Melbourne, Australia
8/10/2004 5:18:31 PM
Oct 08 2004
prev sibling next sibling parent Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <ck5ccl$tit$1 digitaldaemon.com>, Arcane Jill says...


[...]

PS. Here at the Church of Typesafety, we also hold as dogma and eternal truth
that **a character is not a number; a character is not a boolean; and a
character is not a pointer**. I seem to be alone in that opinion, however, so
I'll shut up before another thread spawns.


You're not alone. We are many. And eventually we'll win.

Ciao



 Oct 08 2004



prev sibling next sibling parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Arcane Jill wrote:


 PS. Here at the Church of Typesafety, we also hold as dogma and eternal truth
 that **a character is not a number; a character is not a boolean; and a
 character is not a pointer**. I seem to be alone in that opinion, however, so
 I'll shut up before another thread spawns.


Java, as I used as a basis for the "boolean" question,
does worship both the "boolean" and "pointer" deities:

- boolean is not a number (avoiding the legacy "bool")
   You need to compare numbers against zero: if (i!=0)

- pointer is not a number (they call them references)
   You need to compare them against null: if (p!=null)


However, then they went ahead and defined "char" as
an integer between 0x0000 and 0xFFFF - which was fine
for Unicode-at-the-time, which only knew about UTF-16.

Now, when Unicode is up to v4.0.1 and UTF-32 is here
Java is in almost as much trouble as C - who defined
a character to be in the area of 0x00-0x7F (signed)...

So it seems they both paid for *that* particular blasphemy ?
You should only compare characters against NUL: if (c!='\0')

--anders


PS. I won't even *ask* for a (32-bit) "character" and
     char, wchar and dchar dying a nasty ugly death.
     But *if* it should happen, I wouldn't mourn...

     Working with "fragments" just makes my head hurt.
     I would have preferred a (builtin) "string" type.
     But I do know that Walter is against that too...



 Oct 08 2004



prev sibling  parent reply Rex Couture <Rex_member pathlink.com>  writes:


In article <ck5ccl$tit$1 digitaldaemon.com>, Arcane Jill says...
I seem to be alone in that opinion, ....

No, you are not alone, and this issue is not going to go away.  These are
colossal blunders.

It is so hard for programmers to catch these errors, and so trivial for
compilers, that it is very poor language design to require the programmer to
check data types.



 Oct 08 2004



  parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Rex Couture wrote:


 No, you are not alone, and this issue is not going to go away.
 These are colossal blunders.


I don't agree. They are *deliberate* decisions, to make the language
more "compatible" with C and C++. We just differ a little - in which
parts of the old languages to keep around, and which parts to change...

I too find it strange to keep the old arithmetic logic, since it
also says to "drop C source code compatibility". But it's done.
And since the decision has been made, better leave it for D++ ?


 It is so hard for programmers to catch these errors, and so trivial for
 compilers, that it is very poor language design to require the programmer to
 check data types.


I may disagree with Walter's decision on booleans/characters/strings,
but still like the overall design of D. It does warn about some bugs,
like when you use a non-boolean result such as the common: if (a = b)

And if you really *hate* both C and C++, then maybe D is not the one ?

--anders

PS. There sure are a *lot* of posts about this topic in this newsgroup!
     I missed some because of odd subjects like "compiler compatibility"



 Oct 08 2004



  parent  Rex Couture <Rex_member pathlink.com>  writes:


In article <ck6os7$24an$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

They are *deliberate* decisions, to make the language
more "compatible" with C and C++.


That's what they said about C++ too.  What's so great about complete
compatibility?  Recompilation with stricter rules is almost certain to uncover
lots of errors.



I may disagree with Walter's decision on booleans/characters/strings,....


Ah, so you do disagree.  :-)  I think it's a great language too -- with this one
huge wart.



 Oct 08 2004



prev sibling next sibling parent reply Sean Kelly <sean f4.ca>  writes:


In article <ck1gtq$14r$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

Is it too late to hope for D to get a *real* boolean type ?


Depends on what you're proposing.


That is, not the integer-compatible bit one that is "bool";
but a special-purpose "boolean" type, like the one Java has.



I was hoping for the following code snippets to be illegal:

if (pointer)


Unlikely.  This is too important for C source compatibility.


if (a = b) // just a typo!
if (c = readchar())


These are already both illegal.


i = true + 1;


Messy, but this is even legal in C/C++.


Instead they could be replaced by the equivalent new code:

if (pointer != null)


Arguably a good idea.


if (a == b) // what was meant!
if ((c = readchar()) != 0)


Already necessary.


i = (true ? 1 : 0) + 1;


I like this too.





It seems like "true" and "false" has already been defined
as "bit", which I think is unfortunate. They should have
been "boolean". Better bit names would be "on" and "off".

Can it be added/changed, or are we stuck with C9X/C++ bool?


Until D is standardized, anything is possible.  But this is a religious issue
that has been discussed to death.  If anything is likely to change Walter's mind
about "bit" it's that implementing arrays and slicing and such turned out to be
more complex than expected, and it may not be worth the trouble for what could
also be implemented in a library class.


PS.
Aliasing "bit" to represent "bool" is perfectly fair.
It's even *better* than what my current GCC 3.4 does,
where sizeof(bool) == 4 ! (I'm guessing it uses "int")


I don't think the size of bool should matter, though it would be nice if it were
always one byte (just for the sake of storage).  The C++ standard, however,
doesn't place any storage requirements on bool, so 4 bytes is fair game.


Just that I had hoped for something that was better...
(since C source code compatibility is not an issue ?)
Or did Walter actively CHOOSE the old C style, for D ?


C source code compatibility is an issue, to a degree.  Walter has tried to keep
behavior consistent whenever doing so doesn't result in undesired behavior.
It's what constitutes undesired behavior that's sometimes an issue of
contention.


Sean



 Oct 06 2004



  parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Sean Kelly wrote:

Aliasing "bit" to represent "bool" is perfectly fair.
It's even *better* than what my current GCC 3.4 does,
where sizeof(bool) == 4 ! (I'm guessing it uses "int")


 
 I don't think the size of bool should matter, though it would be nice if it
were
 always one byte (just for the sake of storage).  The C++ standard, however,
 doesn't place any storage requirements on bool, so 4 bytes is fair game.


Yeah, implementing a "bool" in C can be a bit tricky ?
Whether to choose "char" for size or "int" for speed...

"bit" is a lot easier. It's always 0.125 byte. :-)

--anders



 Oct 06 2004



prev sibling next sibling parent reply Arcane Jill <Arcane_member pathlink.com>  writes:


In article <ck1gtq$14r$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

Is it too late to hope for D to get a *real* boolean type ?

That is, not the integer-compatible bit one that is "bool";
but a special-purpose "boolean" type, like the one Java has.


In my time on this forum, this has to qualify as /the/ most Frequently Asked
Question we ever hear. Can't we just put it in the actual FAQ at
http://www.digitalmars.com/d/faq.html and be done with it?

Q. Why doesn't D have a real boolean type?
A. Walter doesn't like it.

Arcane Jill



 Oct 07 2004



 next sibling parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Arcane Jill wrote:


 In my time on this forum, this has to qualify as /the/ most Frequently Asked
 Question we ever hear. Can't we just put it in the actual FAQ at
 http://www.digitalmars.com/d/faq.html and be done with it?


I did see the *question* a lot, just not any answers... :-)
The discussion seemed more to be about the size of "bool" ?


 Q. Why doesn't D have a real boolean type?
 A. Walter doesn't like it.


OK, "bit" it is then... (With the "bool" syntactic sugar)
Just as how it usually works, in C/C++: "non-zero is true"

Too bad,
--anders



 Oct 07 2004



prev sibling  parent reply Ben Hinkle <bhinkle4 juno.com>  writes:


Arcane Jill wrote:


 In article <ck1gtq$14r$1 digitaldaemon.com>,
 =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

Is it too late to hope for D to get a *real* boolean type ?

That is, not the integer-compatible bit one that is "bool";
but a special-purpose "boolean" type, like the one Java has.


 
 In my time on this forum, this has to qualify as /the/ most Frequently
 Asked Question we ever hear. Can't we just put it in the actual FAQ at
 http://www.digitalmars.com/d/faq.html and be done with it?
 
 Q. Why doesn't D have a real boolean type?
 A. Walter doesn't like it.
 
 Arcane Jill


Putting it in the FAQ is fine but I assume you weren't serious about the
answer "Walter doesn't like it". Walter must have some snippets scattered
about with a better rationale.



 Oct 07 2004



  parent reply J C Calvarese <jcc7 cox.net>  writes:


Ben Hinkle wrote:

 Arcane Jill wrote:
 
 

In article <ck1gtq$14r$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...


Is it too late to hope for D to get a *real* boolean type ?

That is, not the integer-compatible bit one that is "bool";
but a special-purpose "boolean" type, like the one Java has.


In my time on this forum, this has to qualify as /the/ most Frequently
Asked Question we ever hear. Can't we just put it in the actual FAQ at
http://www.digitalmars.com/d/faq.html and be done with it?

Q. Why doesn't D have a real boolean type?
A. Walter doesn't like it.

Arcane Jill


 
 
 Putting it in the FAQ is fine but I assume you weren't serious about the
 answer "Walter doesn't like it". Walter must have some snippets scattered
 about with a better rationale.


It's really a religious discussion.

Some people believe in Bool.
Others believe in Bit.

Some people are Reformed Boolists.
Others are Eastern Orthodox Bitians.

Some people attend the Latter-day Church of Bool.
Others are Bit's Witnesses.

Some people use false and true.
Others use yin and yang.

I don't think Walter has written much other than he likes the way it 
works right now.

If someone wants to do some research on the various bit/bool discussions 
over the years, this might be a good place to start: 
http://www.prowiki.org/wiki4d/wiki.cgi?BooleanNotEquBit

The topic should be mentioned in the official FAQ because it's 
definitely frequently asked and I think AJ's answer is as good as any. 
Here's another suggested answer: "If you don't like it, you can 
complain, but you shouldn't expect it to change much. You're not the 
first to broach the subject."

I guess I'm an Agnostic with respect to bit/bool. I just use bit, and 
call it good.

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



 Oct 07 2004



 next sibling parent  Ben Hinkle <bhinkle4 juno.com>  writes:


J C Calvarese wrote:


 Ben Hinkle wrote:

 Arcane Jill wrote:
 
 

In article <ck1gtq$14r$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...


Is it too late to hope for D to get a *real* boolean type ?

That is, not the integer-compatible bit one that is "bool";
but a special-purpose "boolean" type, like the one Java has.


In my time on this forum, this has to qualify as /the/ most Frequently
Asked Question we ever hear. Can't we just put it in the actual FAQ at
http://www.digitalmars.com/d/faq.html and be done with it?

Q. Why doesn't D have a real boolean type?
A. Walter doesn't like it.

Arcane Jill


 
 
 Putting it in the FAQ is fine but I assume you weren't serious about the
 answer "Walter doesn't like it". Walter must have some snippets scattered
 about with a better rationale.


 
 It's really a religious discussion.

 Some people believe in Bool.
 Others believe in Bit.
 
 Some people are Reformed Boolists.
 Others are Eastern Orthodox Bitians.
 
 Some people attend the Latter-day Church of Bool.
 Others are Bit's Witnesses.
 
 Some people use false and true.
 Others use yin and yang.


lol - Amen to that.
 

 I don't think Walter has written much other than he likes the way it
 works right now.
 
 If someone wants to do some research on the various bit/bool discussions
 over the years, this might be a good place to start:
 http://www.prowiki.org/wiki4d/wiki.cgi?BooleanNotEquBit


good link. I'll check out the posts.


 The topic should be mentioned in the official FAQ because it's
 definitely frequently asked and I think AJ's answer is as good as any.
 Here's another suggested answer: "If you don't like it, you can
 complain, but you shouldn't expect it to change much. You're not the
 first to broach the subject."
 
 I guess I'm an Agnostic with respect to bit/bool. I just use bit, and
 call it good.
 


It would be interesting to see the notes from the C++ standard discussions.




 Oct 07 2004



prev sibling  parent  Charles Hixson <charleshixsn earthlink.net>  writes:


J C Calvarese wrote:

 Ben Hinkle wrote:
 

 Arcane Jill wrote:
...


 It's really a religious discussion.
 
 Some people believe in Bool.
 Others believe in Bit.
 
 Some people are Reformed Boolists.
 Others are Eastern Orthodox Bitians.
 
 Some people attend the Latter-day Church of Bool.
 Others are Bit's Witnesses.
 
 Some people use false and true.
 Others use yin and yang.
 
 I don't think Walter has written much other than he likes the way it 
 ...
 I guess I'm an Agnostic with respect to bit/bool. I just use bit, and 
 call it good.
 


I, too, use bit, and consider it a reasonable bool.  But personally 
I expect that eventually I'll write a new class based around byte 
which will express around 212 degrees of certainty (and a few kinds 
of error conditions).  It expressly WON'T include TRUE! and FALSE!. 
  The logic that it uses will always imply that there's some element 
of uncertainty in each step (though probably less than 1 part in 424 
when near the center of the range...toward the edges it will become 
more difficult to become more certain.  (I'd say asymptotically more 
difficult, but that doesn't really apply to a datatype that can be 
contained in a byte.  Still, it captures the idea.)  You could say 
that true would be 213 and false would be -1, but neither one would 
actually be a member of the class.

For now, I'm quite pleased to use bit, and think of it as bool. 
(But I would like it if the bit[n] type were retained as a packed 
array.)



 Oct 08 2004



prev sibling next sibling parent  Rex Couture <Rex_member pathlink.com>  writes:


There seems to be confusion as to what is really wrong with the following code
snippets (note that I have added an example).

The real problem is that D syntax forces the programmer to remember the data
type, and this will inevitably lead to errors, some of which will not be found
during debugging.











 Oct 07 2004



prev sibling  parent reply clayasaurus <clayasaurus gmail.com>  writes:


i don't understand the bool/bit wars.
bit allows me to use true and false, just like bool does.
what am i missing? what is so dangerous about bit's true and false?

Anders F Björklund wrote:

 Is it too late to hope for D to get a *real* boolean type ?
 
 That is, not the integer-compatible bit one that is "bool";
 but a special-purpose "boolean" type, like the one Java has.

 
 
 I was hoping for the following code snippets to be illegal:
 
 if (pointer)
 if (a = b) // just a typo!
 if (c = readchar())
 i = true + 1;
 
 Instead they could be replaced by the equivalent new code:
 
 if (pointer != null)
 if (a == b) // what was meant!
 if ((c = readchar()) != 0)
 i = (true ? 1 : 0) + 1;
 

 
 
 It seems like "true" and "false" has already been defined
 as "bit", which I think is unfortunate. They should have
 been "boolean". Better bit names would be "on" and "off".
 
 Can it be added/changed, or are we stuck with C9X/C++ bool?
 
 --anders
 
 
 PS.
 Aliasing "bit" to represent "bool" is perfectly fair.
 It's even *better* than what my current GCC 3.4 does,
 where sizeof(bool) == 4 ! (I'm guessing it uses "int")
 
 Just that I had hoped for something that was better...
 (since C source code compatibility is not an issue ?)
 Or did Walter actively CHOOSE the old C style, for D ?





 Oct 08 2004



  parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


clayasaurus wrote:


 i don't understand the bool/bit wars.


The wars are over... The bad guys won ;-)




 bit allows me to use true and false, just like bool does.


No, bit allows you to use 1 and 0. There's a difference.

That said; "bool", "true" and "false" are valid keywords.
They work more or less the same in all of C9X, C++ and D.


 what am i missing? what is so dangerous about bit's true and false?


It's not type-safe. Some people think that's a bad thing.

--anders



 Oct 09 2004



 next sibling parent  Sean Kelly <sean f4.ca>  writes:


Anders F Björklund wrote:

 what am i missing? what is so dangerous about bit's true and false?


 
 It's not type-safe. Some people think that's a bad thing.


And bit vectors don't behave quite like vectors of anything else, 
because the bit values are compressed.  This has potential issues for 
template programming (though C++ faces a similar problem with vector<bool>).


Sean



 Oct 09 2004



prev sibling next sibling parent reply "Walter" <newshound digitalmars.com>  writes:


"Anders F Björklund" <afb algonet.se> wrote in message
news:ck85pc$5gl$1 digitaldaemon.com...

 bit allows me to use true and false, just like bool does.


 No, bit allows you to use 1 and 0. There's a difference.


I've been around long enough to have actually constructed computer hardware
out of ttl logic gates. There, 'true' and 'false' are voltage levels. Low
voltage, high voltage, false, true, off, on, 0, 1, all the same.

The D 'bit' type is a true boolean - it can only contain two values.



 Oct 11 2004



 next sibling parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Walter wrote:


bit allows me to use true and false, just like bool does.


No, bit allows you to use 1 and 0. There's a difference.


 
 I've been around long enough to have actually constructed computer hardware
 out of ttl logic gates. There, 'true' and 'false' are voltage levels. Low
 voltage, high voltage, false, true, off, on, 0, 1, all the same.


Hehe, and I sometimes think that *I* am old in this game...

bool vs. boolean and 1 vs. true only makes a difference
if the logic and conditionals is not arithmetic. Otherwise
it's the same, although some find true/false more readable.

Maybe I should start using a "Yao" type with Yin/Yang values ? ;-)


 The D 'bit' type is a true boolean - it can only contain two values.


Yes, that integer type sounds like a better choice for "bool"
than the usual choices of char or int... But I'll just use bool.

And I'll keep saying that bit contains 0/1, and bool false/true ?
Not that it makes any difference in D, just makes me feel better...

Case Closed.
--anders


PS. Thanks for adding the aliases bool/true/false to the language!
     This means I can just don my old C99 / C++ hat, and it'll work.



 Oct 11 2004



prev sibling next sibling parent  Mike Swieton <mike swieton.net>  writes:


On Mon, 11 Oct 2004 02:30:31 -0700, Walter wrote:


 I've been around long enough to have actually constructed computer hardware
 out of ttl logic gates. There, 'true' and 'false' are voltage levels. Low
 voltage, high voltage, false, true, off, on, 0, 1, all the same.


We're not at gate level though. If we wanted to be working on gates, we'd
wouldn't be using a language like D.


 The D 'bit' type is a true boolean - it can only contain two values.


I'm not certain that that argument works: just because it can have only two
values, doesn't mean it's meaningful for representing _any_ given two values.
That is, 0 and 1 are false and true, respectively, only by convention. A
convention which came up because of logic gate design (see above).  On the
other hand, 'true' is true, pretty much by definition. To say that one is the
accepted substitution for another is not to admit that they're equivalent.

A small thought experiment: if bit represented either 18 or -12, two discrete
values, instead of 0 and 1, then which would be true and which would be false?
If you can't answer that in an indisputable manner, than the 'only two values'
argument doesn't hold up.

I admit, I don't really care too much about the boolean issue. But I think
that argument in particular, Walter, doesn't hold water.

Mike Swieton
__
The perversity of the Universe tends towards a maximum.
	- O'Tool's Corollary of Finagle's Law



 Oct 11 2004



prev sibling next sibling parent reply Derek <derek psyc.ward>  writes:


On Mon, 11 Oct 2004 02:30:31 -0700, Walter wrote:


 "Anders F Björklund" <afb algonet.se> wrote in message
 news:ck85pc$5gl$1 digitaldaemon.com...

 bit allows me to use true and false, just like bool does.


 No, bit allows you to use 1 and 0. There's a difference.


 
 I've been around long enough to have actually constructed computer hardware
 out of ttl logic gates. There, 'true' and 'false' are voltage levels. Low
 voltage, high voltage, false, true, off, on, 0, 1, all the same.


I'm not knowledgeable enough to answer this, but can you add, in the
arithmetic sense, two or more voltage levels? 
 

 The D 'bit' type is a true boolean - it can only contain two values.


This is a true statement (excuse the pun). However, it is not a complete
statement of the truth. Although 'bit' is boolean in terms of its potential
values, it is a superset of boolean in that you can do things with bit that
you can't (or shouldn't) do with booleans values. Such as arithmetic.

-- 
Derek
Melbourne, Australia



 Oct 11 2004



 next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Derek wrote:


I've been around long enough to have actually constructed computer hardware
out of ttl logic gates. There, 'true' and 'false' are voltage levels. Low
voltage, high voltage, false, true, off, on, 0, 1, all the same.


 
 I'm not knowledgeable enough to answer this, but can you add, in the
 arithmetic sense, two or more voltage levels? 


That all works just fine, in D:

void main()
{
   printf("5V + 5V = %dV\n", 5 + 5);
   printf("1 + 1 = %d\n", 1 + 1);
   printf("true + true = %d\n", true + true);
}

All the same, like Walter said :-)

--anders



 Oct 11 2004



  parent reply Derek <derek psyc.ward>  writes:


On Mon, 11 Oct 2004 16:13:33 +0200, Anders F Björklund wrote:


 Derek wrote:
 

I've been around long enough to have actually constructed computer hardware
out of ttl logic gates. There, 'true' and 'false' are voltage levels. Low
voltage, high voltage, false, true, off, on, 0, 1, all the same.


 
 I'm not knowledgeable enough to answer this, but can you add, in the
 arithmetic sense, two or more voltage levels? 


 
 That all works just fine, in D:
 
 void main()
 {
    printf("5V + 5V = %dV\n", 5 + 5);
    printf("1 + 1 = %d\n", 1 + 1);
    printf("true + true = %d\n", true + true);
 }
 
 All the same, like Walter said :-)


I guess I didn't make myself clear (again). 

If we say that -12V is True, and +12V is False, can we add them together to
get 0V? And if so, is that result True or False or something else? 

This is a compile-time issue I think. The compiler should prevent people
trying to do arithmetic with boolean values. I'm not adverse to explicit
casts as this is telling the coder reader that the author knew what they
were doing and it is deliberate. The implicit cast to int for bool in D is
an issue.

Thus ...


    printf("true + true = %d\n", cast(int)true + cast(int)true);


would be a deliberate statement by the code author.
-- 
Derek
Melbourne, Australia



 Oct 11 2004



 next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Derek wrote:


 This is a compile-time issue I think. The compiler should prevent people
 trying to do arithmetic with boolean values. I'm not adverse to explicit
 casts as this is telling the coder reader that the author knew what they
 were doing and it is deliberate. The implicit cast to int for bool in D is
 an issue.
 
 Thus ...
 

   printf("true + true = %d\n", cast(int)true + cast(int)true);


 
 would be a deliberate statement by the code author.


Probably even better to disallow *any* cast from boolean to integer ?


That's the way it currently works in the Java language:


 Found 2 semantic errors compiling "test.java":
 
      5.     System.out.println((int) true + (int) true);
                                      ^--^
 *** Semantic Error: An expression of type "boolean" cannot be cast into type
"int".
 
      5.     System.out.println((int) true + (int) true);
                                                   ^--^
 *** Semantic Error: An expression of type "boolean" cannot be cast into type
"int".


However, the canonical way of writing it in Java is:

     System.out.println((true ? 1 : 0) + (true ? 1 : 0));


Which works in C / C++ / D too, with their arithmetic/numeric logic...

--anders


PS. The D compiler *does* prevent you from doing logic with numbers.
     Such as the good old "if (a = b)" typo. (when you meant: "a==b")

   '=' does not give a boolean result





 Oct 11 2004



  parent reply "Walter" <newshound digitalmars.com>  writes:


"Anders F Björklund" <afb algonet.se> wrote in message
news:ckebgf$1mne$1 digitaldaemon.com...

 However, the canonical way of writing it in Java is:

      System.out.println((true ? 1 : 0) + (true ? 1 : 0));


No thanks :-)



 Oct 11 2004



  parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Walter wrote:


     System.out.println((true ? 1 : 0) + (true ? 1 : 0));


 
 No thanks :-)


I would say adding two booleans was a pretty contrived example...


It's actually not that big a change, especially not from C99/C++.
I've ported some C/C++ code to Java, and you usually just change:

if (!pointer)
-->	if (pointer == null)
if (integer)
-->	if (integer != 0)
while (character)
-->	while (character != '\0')
flag |= boolean << SHIFT;
-->	flag |= (boolean ? 1 : 0) << SHIFT;

There is *nothing* stopping us from making such code changes already?
Even if all we have is a "bool" type... We do have "true" and "false".


If it's the same to you Walter, I do suggest two rather minor changes:

1) Make the type (if there is one ?) of "true" and "false" into "bool"
    (true and false are keywords, but I do think they are "bit" now?)

2) Make the default value for bit "0", and not "false" like it is now.
    http://www.digitalmars.com/d/type.html - Default Initializer (.init)

That would allow for a GRADUAL change for D - from the current C99 bool 



As long as bit only has the values 1 and 0, and bool only has true/false
all we are missing at the moment are some compiler checks and warnings?

While I am it, could we make the alias "bool" into a reserved D keyword?
(since it's in the system headers anyway, and "true" and "false" are kw)


Ecumenic greetings,
--anders


PS. It's interesting to see that the compiler does check conditionals
     for boolean expressions already, even if there is no boolean type.

     Makes you wonder how much work it would be to make this D change ?
     (if anyone should want to go ahead and prepare the patch, I mean)



 Oct 11 2004



  parent reply Daniel Horn <hellcatv hotmail.com>  writes:


 It's actually not that big a change, especially not from C99/C++.
 I've ported some C/C++ code to Java, and you usually just change:
 
 if (!pointer)
 -->    if (pointer == null)


  porting java code to D gets even trickier
don't want to call opEqual do you? better "triple" check it's null
if (pointer === null)


 if (integer)
 -->    if (integer != 0)
 while (character)
 -->    while (character != '\0')
 flag |= boolean << SHIFT;
 -->    flag |= (boolean ? 1 : 0) << SHIFT;
 
 PS. It's interesting to see that the compiler does check conditionals
     for boolean expressions already, even if there is no boolean type.
 
     Makes you wonder how much work it would be to make this D change ?
     (if anyone should want to go ahead and prepare the patch, I mean)





 Oct 11 2004



  parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Daniel Horn wrote:


 if (!pointer)
 -->    if (pointer == null)


 
  porting java code to D gets even trickier
 don't want to call opEqual do you? better "triple" check it's null
 if (pointer === null)


I'm new here. :-)

Am I right in believing that == and != should be used with pointers,
and that === and !== should be used with references (avoiding *NULL) ?

--anders



 Oct 12 2004



prev sibling  parent reply Lars Ivar Igesund <larsivar igesund.net>  writes:


Derek wrote:

 On Mon, 11 Oct 2004 16:13:33 +0200, Anders F Björklund wrote:
 
 

Derek wrote:



I've been around long enough to have actually constructed computer hardware
out of ttl logic gates. There, 'true' and 'false' are voltage levels. Low
voltage, high voltage, false, true, off, on, 0, 1, all the same.


I'm not knowledgeable enough to answer this, but can you add, in the
arithmetic sense, two or more voltage levels? 


That all works just fine, in D:

void main()
{
   printf("5V + 5V = %dV\n", 5 + 5);
   printf("1 + 1 = %d\n", 1 + 1);
   printf("true + true = %d\n", true + true);
}

All the same, like Walter said :-)


 
 
 I guess I didn't make myself clear (again). 
 
 If we say that -12V is True, and +12V is False, can we add them together to
 get 0V? And if so, is that result True or False or something else? 
 
 This is a compile-time issue I think. The compiler should prevent people
 trying to do arithmetic with boolean values. I'm not adverse to explicit
 casts as this is telling the coder reader that the author knew what they
 were doing and it is deliberate. The implicit cast to int for bool in D is
 an issue.
 
 Thus ...
 
 

   printf("true + true = %d\n", cast(int)true + cast(int)true);


 
 
 would be a deliberate statement by the code author.


Are you asking about how ports and transistors work physically? In that 
case the answer to your question, in short, is no.
If I remember my dig.tech. correctly, a value (bit) is decided by the 
voltage in some unit, 0V equals 0 and 3-5V (depending on the processor, 
actually) equals 1. Then you move these bits around through ports made 
of transistors. Different ports can do different things, but among the 
most common are XOR, AND, NAND. Most of them (all?) take two inputs and 
has an output. One such port (or was it gate?) can only produce a one 
bit result. Thus to be able to add larger numbers you need to have many 
bits and bytes and gates and ports and put them together in a smart way. 
I hope I answered the correct question in a somewhat understandable way :)

Lars Ivar Igesund



 Oct 11 2004



  parent  "Walter" <newshound digitalmars.com>  writes:


"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:ckekr7$1vcf$1 digitaldaemon.com...

 Are you asking about how ports and transistors work physically? In that
 case the answer to your question, in short, is no.
 If I remember my dig.tech. correctly, a value (bit) is decided by the
 voltage in some unit, 0V equals 0 and 3-5V (depending on the processor,
 actually) equals 1. Then you move these bits around through ports made
 of transistors. Different ports can do different things, but among the
 most common are XOR, AND, NAND. Most of them (all?) take two inputs and
 has an output. One such port (or was it gate?) can only produce a one
 bit result. Thus to be able to add larger numbers you need to have many
 bits and bytes and gates and ports and put them together in a smart way.
 I hope I answered the correct question in a somewhat understandable way :)


Back when I was a kid, I had a toy where you set some mechanical flip flops
up with a 'program' and then rolled marbles down, which flowed through the
'program' gates and operated the flip flops. You could set it up for several
operations, like doing a binary add.



 Oct 11 2004



prev sibling  parent  Sean Kelly <sean f4.ca>  writes:


In article <29gc8s0lsj54.1lob303fnjsv0$.dlg 40tude.net>, Derek says...

I'm not knowledgeable enough to answer this, but can you add, in the
arithmetic sense, two or more voltage levels? 


Certainly.  AFAIK the early computers were all base 10.  But boolean math is
much easier to implement in modern hardware.


Sean



 Oct 11 2004



prev sibling  parent  Matthias Becker <Matthias_member pathlink.com>  writes:


I've been around long enough to have actually constructed computer hardware
out of ttl logic gates. There, 'true' and 'false' are voltage levels. Low
voltage, high voltage, false, true, off, on, 0, 1, all the same.

The D 'bit' type is a true boolean - it can only contain two values.


Well, wasn't this all about typesafety?


Anyway, I don't get you. At the end everything in the computer is high and low
voltage, so should we stop thinking in functions, objects and the like and
rather think in some binary format? Why do we actualy use a high level language?
We want to abstract things to a level at which things get easy for humans. We
aren't interested whether it's all 1 and 0 for the computer.


-- Matthias Becker



 Oct 11 2004



prev sibling  parent reply Rex Couture <Rex_member pathlink.com>  writes:


In article <ck85pc$5gl$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

It's not type-safe. Some people think that's a bad thing.


It is a bad thing.  I would go further and say that if we can't agree on the
need for type safety by the year 2004, then we haven't learned very much.  You
can't promote a new language for the 21st century that bypasses type safety.

The issue of the size of a boolean variable is another issue, which is stricly a
matter of implementation.  It makes no logical difference whether a boolean
variable is 1 bit or more.  You can even have more than one size of
type-compatible boolean, which is now the case -- as long as a boolean
expression is required for a conditional statement, which is not now the case.



 Oct 11 2004



  parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Rex Couture wrote:


It's not type-safe. Some people think that's a bad thing.





 It is a bad thing.  I would go further and say that if we can't agree on the
 need for type safety by the year 2004, then we haven't learned very much.  You
 can't promote a new language for the 21st century that bypasses type safety.


Guess you could say the same of pointers, goto, or even compiled code ?




Walter made his choice.
--anders



 Oct 11 2004



  parent reply Rex Couture <Rex_member pathlink.com>  writes:


In article <cke4ui$1fvs$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

Rex Couture wrote:

...if we can't agree on the
 need for type safety by the year 2004, then we haven't learned very much. 
>>You can't promote a new language for the 21st century that bypasses type
>>safety.


Guess you could say the same of pointers, goto, or even compiled code ?



You're missing the point.  In the case of boolean expressions in conditional
statements, by allowing integers as booleans we are not only giving up type
checking, but we are giving up the possibility of type checking.  Under current
rules, the compiler simply cannot check whether you have used the correct data
type.

Walter has given two reasons of which I am aware, for the structure of booleans.
First, checking an integer for a 0 value is fast, and faster than checking it
for a 0 or 1 value.  This has nothing to do with type checking for boolean
expressions at compile time, but it has confused the discussion.  No one has yet
demonstrated how type checking could possibly affect performance.

If I understand Walter correctly, the real reason is so D will compile C code
without modification.  The price for this is that you can't type-check your
shiny new code either.  Equally bad, if previous C code is sufficiently long to
involve a major effort to fix boolean expressions, you will almost certainly
compile errors right along with the good code.  I don't find either to be a very
satisfactory situation.  In the opinions of many people, these situations do not
reflect good coding practice.

I note that several members of this discussion group can't wait for D++ or some
such, so we can change the situation.  It remains to be seen whether this is
realistic.



 Oct 11 2004



  parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Rex Couture wrote:


Guess you could say the same of pointers, goto, or even compiled code ?


 
 You're missing the point.  In the case of boolean expressions in conditional
 statements, by allowing integers as booleans we are not only giving up type
 checking, but we are giving up the possibility of type checking.  Under current
 rules, the compiler simply cannot check whether you have used the correct data
 type.


Yeah, that is why I *started* this thread - asking for a real boolean ;)

I wanted a non-arithmetic "boolean" like in Java, not "bool" as in C/C++


 Walter has given two reasons of which I am aware, for the structure of
booleans.
 First, checking an integer for a 0 value is fast, and faster than checking it
 for a 0 or 1 value.  This has nothing to do with type checking for boolean
 expressions at compile time, but it has confused the discussion.  No one has
yet
 demonstrated how type checking could possibly affect performance.


That argument just sounds like a case of premature optimization to me...

I'm not sure why boolean couldn't be *implemented* the same way as bit ?


 If I understand Walter correctly, the real reason is so D will compile C code
 without modification.  The price for this is that you can't type-check your
 shiny new code either.  Equally bad, if previous C code is sufficiently long to
 involve a major effort to fix boolean expressions, you will almost certainly
 compile errors right along with the good code.  I don't find either to be a
very
 satisfactory situation.  In the opinions of many people, these situations do
not
 reflect good coding practice.


D breaks with other C code on purpose, so that argument doesn't hold.

http://www.digitalmars.com/d/overview.html says:
"C source code compatibility. Extensions to C that maintain source 
compatibility
have already been done (C++ and ObjectiveC). Further work in this area 
is hampered
by so much legacy code it is unlikely that significant improvements can 
be made."

I think the real reason is that Walter *prefers* the "sloppy" C syntax ?


 I note that several members of this discussion group can't wait for D++ or some
 such, so we can change the situation.  It remains to be seen whether this is
 realistic.


I gave up, and moved on. If I can live with "bool" in C/C++, I can in D.

--anders



 Oct 11 2004



  parent reply Rex Couture <Rex_member pathlink.com>  writes:


In article <ckenm4$21c1$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

Yeah, that is why I *started* this thread - asking for a real boolean ;)
I wanted a non-arithmetic "boolean" like in Java, not "bool" as in C/C++


My apologies, I guess I misunderstood your message, and I certainly forgot who
wrote what.



http://www.digitalmars.com/d/overview.html says:
"C source code compatibility...."

I think the real reason is that Walter *prefers* the "sloppy" C syntax ?


You're right.  In the language overview, he argues rightly for source-code
compatibility as a feature to drop.



I gave up, and moved on. If I can live with "bool" in C/C++, I can in D.


My suggestion is (gasp) Hungarian notation.



 Oct 11 2004



  parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Rex Couture wrote:


I gave up, and moved on. If I can live with "bool" in C/C++, I can in D.


 
 My suggestion is (gasp) Hungarian notation.


Are you talking about something like this, perhaps ?
bit bFlag = true;

I'm not sure how the hungarian warts would help here ?
And if you are, then I want nothing to do with it :-)

--anders



 Oct 11 2004



 next sibling parent  Sjoerd van Leent <svanleent wanadoo.nl>  writes:


Anders F Björklund wrote:

 I'm not sure how the hungarian warts would help here ?
 And if you are, then I want nothing to do with it :-)
 
 --anders


I'm with you. Hungarian notation is just ugly, plain ugly, nothing more 
but sure nothing less than ugly.

Regards,
Sjoerd



 Oct 11 2004



prev sibling  parent reply Rex Couture <Rex_member pathlink.com>  writes:


In article <ckerfa$2484$2 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

Rex Couture wrote:

 My suggestion is (gasp) Hungarian notation.


I'm not sure how the hungarian warts would help here ?



Simple.


at least allow you to see that you are using valid boolean expressions, and not
some kind of integer or pointer, even if the compiler cannot check it.

============================================
Note that

is now legal, even if it's a pointer, an integer, or boolean.  Good luck trying
to read the code.  The meaning depends on the variable type!
============================================

If the compiler can't do type checking, then the programmer must, as ugly as
that may be.  Are you SURE the bool type solves your problems?  See what I mean?



 Oct 11 2004



  parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Rex Couture wrote:


 Simple.


 at least allow you to see that you are using valid boolean expressions, and not
 some kind of integer or pointer, even if the compiler cannot check it.


This cure is worse than the disease. Either the compiler
checks the types of the variables, or no-one does...


 Note that

 is now legal, even if it's a pointer, an integer, or boolean.  Good luck trying
 to read the code.  The meaning depends on the variable type!


Nah, it has the same meaning for all: check for non-zero.
Real Programmers *know* that NULL is 0 and false is 0...


 If the compiler can't do type checking, then the programmer must, as ugly as
 that may be.  Are you SURE the bool type solves your problems?  See what I
mean?


If logic is arithmetic, there is no *need* to check types.
It's also a little less "safe" than having separate types.

--anders

PS. Real Programmers don't eat quiche, either.
     http://www.ee.ryerson.ca:8080/~elf/hack/realmen.html



 Oct 11 2004



  parent reply Rex Couture <Rex_member pathlink.com>  writes:


In article <ckeub6$26h5$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

Rex Couture wrote:


 Simple.


 at least allow you to see that you are using valid boolean expressions, and not
 some kind of integer or pointer, even if the compiler cannot check it.


This cure is worse than the disease. Either the compiler
checks the types of the variables, or no-one does...


Exactly.



 Note that

 is now legal, even if it's a pointer, an integer, or boolean.  Good luck trying
 to read the code.  The meaning depends on the variable type!


Nah, it has the same meaning for all: check for non-zero.
Real Programmers *know* that NULL is 0 and false is 0...


I think you're joking.  Just in case, the significance of the 0 or nonzero
result depends strongly on the type.



PS. Real Programmers don't eat quiche, either.
     http://www.ee.ryerson.ca:8080/~elf/hack/realmen.html


Now I know you're joking.  This is a classic spoof.  Speaking as someone who has
used card punches and FORTRAN IV, I can attest that Real Programmers have
crashed a few multimillion dollar space probes.



 Oct 11 2004



  parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Rex Couture wrote:


Nah, it has the same meaning for all: check for non-zero.
Real Programmers *know* that NULL is 0 and false is 0...


 
 I think you're joking.  Just in case, the significance of the 0
 or nonzero result depends strongly on the type.


Not to the computer, it doesn't. :-) (yes, I was half-joking)


 Now I know you're joking.  This is a classic spoof.  Speaking as someone who
has
 used card punches and FORTRAN IV, I can attest that Real Programmers have
 crashed a few multimillion dollar space probes.


I guess "Real Programmers aren't afraid of live beta tests" ?

--anders



 Oct 12 2004