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

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.

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

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.

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 usage into the new type-safe bool usage that C# (of all languages) has?


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)

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

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

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.
#  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.

============================================
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!
============================================

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?

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 ?


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*
(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.


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.

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...

> 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...

> 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