On Sun, 26 Feb 2006 19:39:48 +1100, bobef <bobef@lessequal.com> wrote:

> Derek Parnell wrote:
>>  Zero is frequently used to implement the concept of falsehood and likewise non-zero for truth, however the semantics of integers is not the same as the semantics of booleans. But because many C programers are just *so* used to thinking this way they have become to believe that zero *is* falsehood rather than just a number chosen to implement the concept.
>>
>
> Just thoughts...
>
> Well back in school we were learning boolean algebra. (for some electrical crap... I don't remember... I don't care...). Even if we take just the name 'boolean algebra' it means it used for calculations, which means it is number not falsehood...

Not so. It is possible to create 'calculations' using purely logic expressions. The result is not a number but one of 'false' or 'true' (or unknown). Fuzzy logic calulations are more of a numerical field (probablilty theory).

> After all it used for all these logical operators which operate with numbers not falsehood...

Well I'm sure it operates on relationships between numbers and not the numbers themselves.

> If we say it is not calculations and it is logical operations, well it is not, else it would be only true, false, if a to b is false and c to b is true then a to c is ... this kind of stuff. But it is actually used for numbers and calculations, because 01101010<<0202 is not logic anymore it is mathematics which is also logic but other kind than true/false, logic for the quantity of things not their rightness...

Ok whatever ... but I was talking about what one gets when one compares things with other things in relative terms or similar...

e.g.   a < b  ==> true or false


> And one more thing. If it is falsehood indeed, then it is something abstract. Technically speaking True and False have any meaning only in the context of each other, i.e. in the context of some logic, system or whatever, not in the context of numbers. So how are you going to convert from number to falsehood?

By agreeing on a convention that is convenient.

> This would limit us to writing only bool a=true || bool a=false, which seems annoying to me. bool a=1 is shorter ;].

Yes it is shorter, but it is not descriptive of your intention. Did you want 'a' to be set to 1 or to true? In other words, is the 'bool' a mistake and really meant 'int'? Because the use of 1 in this way is ambiguous it ought to be made cleaner / clearer to future maintainers.

> Plus there will be no if(a), if(b), because a is always true or always false by itself, it should relate to something else to be right or wrong, so we will always have to write if(a==1), if(b==null) instead, so I like it this way ;]

I take the syntax form  'if (<numeric-expression>)' to just be shorthand for 'if (<numeric-expression> != 0)' and thus it would still be valid syntax and get you the result you were expecting. No relaxation of boolean sematrics is required.

> Am I talking nonsese? :)

No.

-- 
Derek Parnell
Melbourne, Australia

Derek Parnell wrote:

> In other words, is the 'bool' a mistake and really meant 'int'? Because the use of 1 in this way is ambiguous it ought to be made cleaner / clearer to future maintainers.

I think this is the case. In programming when one says bool, he actually means int... So I believe making it real bool is something we don't need, because it works just fine this way. What we have to do (maybe, I don't need it personally) is to think of new name for a type which is true relative to non zero and false relative to zero... Then it will work with the current state of programming languages and will not conflict with the name bool. Although in computers many words are uses with different meaning... I don't know... I lost the original thought already...

Derek Parnell wrote:
> Walter is still living in the C/C++ past with this concept, which is  strange seeing he has implemented so many progressive concepts in D.  Boolean as an integer is just retro.

So am I.

Booleans have to be int. A boolean may have any "numeric" value, but if  implicitly cast to a numeric type, it should return 1 or 0.

D IS A PRACTICAL PROGRAMMING LANGUAGE.

Forcing booleans to be 1/0 all the way is just academic, purist, impractical bigotry. About as smart as having the bit type.

(Besides, if booleans, as some say here, are _only_ abstract concepts, then we might as well decide to have 0 mean true and 1 mean false. Heh, there's only one truth but millions of lies! But we live in a world with other people. And computers.)

Now, specifying 0 to mean false and everything else to mean not-false, we go along with the hardware, the computer industry, half a century of programming PRACTICE, and make life less difficult for anybody with a professional programming background before moving to D.

Anybody who wants a tight-ass boolean, can define one for themselves.

////

Now off to the Olympic Final in ice hockey: Finland - Sweden!!!

In article <op.s5kj5uym6b8z09@ginger.vic.bigpond.net.au>, Derek Parnell says...
>
>On Sun, 26 Feb 2006 15:33:18 +1100, Tom <Tom_member@pathlink.com> wrote:
>
>> In article <op.s5kaquba6b8z09@ginger.vic.bigpond.net.au>, Derek Parnell says...
>>>
>>> On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright
>>
>> [snip]
>>
>>>   d = a + b + c;
>>
>> Sorry, how is the above different than the next?
>>
>>>   e = a + b + c; // In a decent implentation, this should have failed to
>>> compile
>>
>> I mean, in a decent implementation, would it be right to allow '+'
>> (numeric add
>> operator) between boolean vars?
>>
>
>No it wouldn't either. I rushed my response as I was going out visiting my Dad - he turned 74 today.

That's ok, i see. :-) Wish your dad a happy birthday.

Regards,

Tom;

Georg Wrede wrote:
> Derek Parnell wrote:
>> Walter is still living in the C/C++ past with this concept, which is  strange seeing he has implemented so many progressive concepts in D.  Boolean as an integer is just retro.
> 
> So am I.
> 
> Booleans have to be int. A boolean may have any "numeric" value, but if  implicitly cast to a numeric type, it should return 1 or 0.
> 
> D IS A PRACTICAL PROGRAMMING LANGUAGE.
> 
> Forcing booleans to be 1/0 all the way is just academic, purist, impractical bigotry. About as smart as having the bit type.
> 
> (Besides, if booleans, as some say here, are _only_ abstract concepts, then we might as well decide to have 0 mean true and 1 mean false. Heh, there's only one truth but millions of lies! But we live in a world with other people. And computers.)
> 
> Now, specifying 0 to mean false and everything else to mean not-false, we go along with the hardware, the computer industry, half a century of programming PRACTICE, and make life less difficult for anybody with a professional programming background before moving to D.
> 
> Anybody who wants a tight-ass boolean, can define one for themselves.
> 
> ////
> 
> Now off to the Olympic Final in ice hockey: Finland - Sweden!!!

How would having a builtin, "purist" boolean type preclude using integers as a boolean type, in all the old ways you describe? Just as a curiosity, how have you been burned in the past by "purist" thinking like this to make you so passionately against it?

In article <dtsgbj$1h6u$3@digitaldaemon.com>, Kyle Furlong says...
>
>Georg Wrede wrote:
>> Derek Parnell wrote:
>>> Walter is still living in the C/C++ past with this concept, which is strange seeing he has implemented so many progressive concepts in D. Boolean as an integer is just retro.
>> 
>> So am I.
>> 
>> Booleans have to be int. A boolean may have any "numeric" value, but if
>>  implicitly cast to a numeric type, it should return 1 or 0.
>> 
>> D IS A PRACTICAL PROGRAMMING LANGUAGE.
>> 
>> Forcing booleans to be 1/0 all the way is just academic, purist, impractical bigotry. About as smart as having the bit type.
>> 
>> (Besides, if booleans, as some say here, are _only_ abstract concepts, then we might as well decide to have 0 mean true and 1 mean false. Heh, there's only one truth but millions of lies! But we live in a world with other people. And computers.)
>> 
>> Now, specifying 0 to mean false and everything else to mean not-false, we go along with the hardware, the computer industry, half a century of programming PRACTICE, and make life less difficult for anybody with a professional programming background before moving to D.
>> 
>> Anybody who wants a tight-ass boolean, can define one for themselves.
>> 
>> ////
>> 
>> Now off to the Olympic Final in ice hockey: Finland - Sweden!!!
>
>How would having a builtin, "purist" boolean type preclude using integers as a boolean type, in all the old ways you describe? Just as a curiosity, how have you been burned in the past by "purist" thinking like this to make you so passionately against it?

I'd like to hear the answer :) .
Have to stay at the purists side on this one. I like bool to be bool cause I'm
that kind of guy that can't tolerate inconsistence (however I do tolerate it
cause don't have much of a choice right now) and I'm putting all my hope in D.
However both (the purist and the pragmatic) ways could coexist in the same
language I guess.

Tom;

Derek Parnell wrote:
> On Sun, 26 Feb 2006 17:29:03 +1100, Wang Zhen <nehzgnaw@gmail.com> wrote:
> 
>> Derek Parnell wrote:
>>
>>> On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright   <newshound@digitalmars.com> wrote:
>>>
>>>> Lots of new stuff, I added new threads for them in the digitalmars.D
>>>> newsgroup.
>>>>
>>>  Well you almost got bool right <G> Everything except that it does  implicit  conversion to int. That is just a cheap cop out for lazy  coding, IMNSHO.
>>
>>
>> Pardon my ignorance,
> 
> 
> That's okay.
> 
>> but why does D need a primitive type for booleans in the first place?  What's wrong with "alias ubyte bool;" or "alias int bool;"?
> 
> 
> The short answer is that booleans are not numbers. They represent truth  and falsehood.
> 
>> Can't we simply treat zero as false and non-zero as true as we C  programmers always do?
> 
> 
> *We* are not C programmers ;-) *We* have grown up from that baby-talk ;-)
> 
> Zero is frequently used to implement the concept of falsehood and likewise  non-zero for truth, however the semantics of integers is not the same as  the semantics of booleans. But because many C programers are just *so*  used to thinking this way they have become to believe that zero *is*  falsehood rather than just a number chosen to implement the concept.

32-bit int is frequently used to implement the concept of integers, but they are semantically different. So what? Be a language purist and refuse to call int an integer until programmers can store arbitrary integers without having to worry about the implementation details?



> It is quite possible for a language to implement falsehood/truth is ways  other than using integers but even if they do, the compiler can still  ensure that the sematics are adhered to rather than continue using integer  sematics.
> 
> The only thing I can see wrong with D's new boolean is that it still  pretends its a number. Why is this wrong? Because it can lead to coding  mistakes and abuse. Thus making maintenance more costly than it needed to  be.

Pretending that bool is not a number can possibly lead to more confusion and misuse. Besides, many other features can also be abused in a practical language like D. Abandon them all just in case some unconscious programmer might make a mistake?


> Walter is still living in the C/C++ past with this concept, which is  strange seeing he has implemented so many progressive concepts in D.  Boolean as an integer is just retro.

I'm still not convinced why oldschool integer bools are inferior to newschool bools which may be abused by pointer tricks anyway.

Tom wrote:
> In article <dtsgbj$1h6u$3@digitaldaemon.com>, Kyle Furlong says...
> 
>>Georg Wrede wrote:
>>
>>>Derek Parnell wrote:
>>>
>>>>Walter is still living in the C/C++ past with this concept, which is  strange seeing he has implemented so many progressive concepts in D.  Boolean as an integer is just retro.
>>>
>>>So am I.
>>>
>>>Booleans have to be int. A boolean may have any "numeric" value, but if 
>>> implicitly cast to a numeric type, it should return 1 or 0.
>>>
>>>D IS A PRACTICAL PROGRAMMING LANGUAGE.
>>>
>>>Forcing booleans to be 1/0 all the way is just academic, purist, impractical bigotry. About as smart as having the bit type.
>>>
>>>(Besides, if booleans, as some say here, are _only_ abstract concepts, then we might as well decide to have 0 mean true and 1 mean false. Heh, there's only one truth but millions of lies! But we live in a world with other people. And computers.)
>>>
>>>Now, specifying 0 to mean false and everything else to mean not-false, we go along with the hardware, the computer industry, half a century of programming PRACTICE, and make life less difficult for anybody with a professional programming background before moving to D.
>>>
>>>Anybody who wants a tight-ass boolean, can define one for themselves.
>>>
>>>////
>>>
>>>Now off to the Olympic Final in ice hockey: Finland - Sweden!!!
>>
>>How would having a builtin, "purist" boolean type preclude using integers as a boolean type, in all the old ways you describe? Just as a curiosity, how have you been burned in the past by "purist" thinking like this to make you so passionately against it?
> 
> 
> I'd like to hear the answer :) .
> Have to stay at the purists side on this one. I like bool to be bool cause I'm
> that kind of guy that can't tolerate inconsistence (however I do tolerate it
> cause don't have much of a choice right now) and I'm putting all my hope in D.
> However both (the purist and the pragmatic) ways could coexist in the same
> language I guess.
> 
> Tom;


I'm curious to know how you can tolerate the much impure int and real types while highly demanding a pure boolean. An integer bool is at least a superset of true booleans. Does that really bother people more?

In article <6r18d3-3l7.ln1@birke.kuehne.cn>, Thomas Kuehne says...
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Walter Bright schrieb am 2006-02-26:
>> Lots of new stuff, I added new threads for them in the digitalmars.D newsgroup.
>>
>> http://www.digitalmars.com/d/changelog.html
>>
>
>Missing from the changelog:
>
>added DMD Script Shell http://www.digitalmars.com/d/rdmd.html
>
>Thomas
>
>
>-----BEGIN PGP SIGNATURE-----
>
>iD8DBQFEAVhF3w+/yD4P9tIRAqh3AKCQdzlVeGTLvmBAM8hQlk01WFKUlACeIQ6R
>pX7C/c/3ctdZ7xqjJ06VnqI=
>=rLQz
>-----END PGP SIGNATURE-----

With an eye toward integrating rdmd with the compiler (as is mentioned in the doc), if anyone has the time, please review the rdmd source code to spot any potential security issues, subtle bugs, etc.

The most recent version of the source code (for both *nix and Windows) is here: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.announce/2673

Thanks,

- Dave

Wang Zhen wrote:
> Derek Parnell wrote:
>> On Sun, 26 Feb 2006 17:29:03 +1100, Wang Zhen <nehzgnaw@gmail.com> wrote:
>>
>>> Derek Parnell wrote:
>>>
>>>> On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright   <newshound@digitalmars.com> wrote:
>>>>
>>>>> Lots of new stuff, I added new threads for them in the digitalmars.D
>>>>> newsgroup.
>>>>>
>>>>  Well you almost got bool right <G> Everything except that it does  implicit  conversion to int. That is just a cheap cop out for lazy  coding, IMNSHO.
>>>
>>>
>>> Pardon my ignorance,
>>
>>
>> That's okay.
>>
>>> but why does D need a primitive type for booleans in the first place?  What's wrong with "alias ubyte bool;" or "alias int bool;"?
>>
>>
>> The short answer is that booleans are not numbers. They represent truth  and falsehood.
>>
>>> Can't we simply treat zero as false and non-zero as true as we C  programmers always do?
>>
>>
>> *We* are not C programmers ;-) *We* have grown up from that baby-talk ;-)
>>
>> Zero is frequently used to implement the concept of falsehood and likewise  non-zero for truth, however the semantics of integers is not the same as  the semantics of booleans. But because many C programers are just *so*  used to thinking this way they have become to believe that zero *is*  falsehood rather than just a number chosen to implement the concept.
> 
> 32-bit int is frequently used to implement the concept of integers, but they are semantically different. So what? Be a language purist and refuse to call int an integer until programmers can store arbitrary integers without having to worry about the implementation details?
> 
> 
> 
>> It is quite possible for a language to implement falsehood/truth is ways  other than using integers but even if they do, the compiler can still  ensure that the sematics are adhered to rather than continue using integer  sematics.
>>
>> The only thing I can see wrong with D's new boolean is that it still  pretends its a number. Why is this wrong? Because it can lead to coding  mistakes and abuse. Thus making maintenance more costly than it needed to  be.
> 
> Pretending that bool is not a number can possibly lead to more confusion and misuse. Besides, many other features can also be abused in a practical language like D. Abandon them all just in case some unconscious programmer might make a mistake?
> 
> 
>> Walter is still living in the C/C++ past with this concept, which is  strange seeing he has implemented so many progressive concepts in D.  Boolean as an integer is just retro.
> 
> I'm still not convinced why oldschool integer bools are inferior to newschool bools which may be abused by pointer tricks anyway.

The point has to do with the type system. Yes, you can always hack any type by using pointer tricks. So what is the point of having a type system in the first place? Having all booleans as integers is just wrong, they have different constraints, are different kinds of entities, even if they are backed by the same kind of storage.