View mode: basic / threaded / horizontal-split · Log in · Help
October 11, 2004
Re: Too late for boolean ?
In article <ckeub6$26h5$1@digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>Rex Couture wrote:
>
>> Simple.
>> #  if (bVariable) ...
>> #  if (pDeceptiveVariableName !=0) ...
>> 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
>> #  if (DeceptiveVariableName) ...
>> 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.
October 11, 2004
Re: Too late for boolean ?
Anders F Björklund wrote:

> Walter wrote:
> 
>>>I just wanted to point out that C(9X) and C++ chose one solution,
>>>and that Java and C# chose another ? D currently sides with the
>>>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*
> (but still arithmetic), like it is in C++. And best would be as in C#:
> 
> 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
> the new programmers growing up with new languages like C# and Java ?
> 
> --anders
> 
> 
> PS. I happen to like C, as I grew up on it. Just thought D was modern.
October 11, 2004
Re: Too late for boolean ?
> 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)
October 12, 2004
Re: Too late for boolean ?
"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.
October 12, 2004
Re: Too late for boolean ?
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
October 12, 2004
Re: Too late for boolean ? (keywords)
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.


Originally; I said that I wanted a type-safe boolean type like in C#,
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 ?
  (compromise between the "extreme" standpoints of C99 and C#, that is)


> 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,
in favor of the "other languages" in the C family like: C, C++ and C#.

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:

bool evolution:    C89 --> C99 --> C++ --> C#
                            ^
                        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
October 12, 2004
Re: Too late for boolean ?
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
October 12, 2004
Re: Too late for boolean ? (keywords)
"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".

> Originally; I said that I wanted a type-safe boolean type like in C#,
> 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 ?
>    (compromise between the "extreme" standpoints of C99 and C#, that is)
>

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,
> in favor of the "other languages" in the C family like: C, C++ and C#.

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:
>
> bool evolution:    C89 --> C99 --> C++ --> C#
>                              ^
>                          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
October 12, 2004
Re: Too late for boolean ? (keywords)
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 ?
>>   (compromise between the "extreme" standpoints of C99 and C#, that is)

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

--anders
October 12, 2004
Re: Too late for boolean ? (keywords)
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
2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home