October 07, 2004
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.


#  if (pointer)...; // I forgot it was a pointer!  Disaster #  i = trueVariable + 1;  //I thought this was an integer

#  int data;
#  boolean bData;
#  if (data)...  // I thought this was boolean too


October 07, 2004
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/
October 07, 2004
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. In this area C++ is the closest to D than Java/C#/Python/etc.
October 07, 2004
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
October 08, 2004
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
October 08, 2004
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
October 08, 2004
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.



October 08, 2004
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
October 08, 2004
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


October 08, 2004
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...