www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - true is not not zero

reply Derek Parnell <derek psych.ward> writes:
Would it be useful if the compiler saw '<expression> == true' as
'<expression> != 0'? 

Then these would be equivalent ...

   if (Fld) ...

and

   if (Fld == true) ...

because currently these are not equivalent.

import std.stdio;
int main()
{
    int A = 2;

    if (A) writefln("A");
    if (A!=0) writefln("A!=0");
    if (A==true) writefln("A==true");

    return 0;
}

-- 
Derek Parnell
Melbourne, Australia
31/08/2005 9:43:47 PM
Aug 31 2005
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:jag0mz602hw$.u59i5vti46wf$.dlg 40tude.net...
 Would it be useful if the compiler saw '<expression> == true' as
 '<expression> != 0'?

 Then these would be equivalent ...

   if (Fld) ...

 and

   if (Fld == true) ...

 because currently these are not equivalent.

I'm not sure if you're looking for utility or for syntactic sugar ;) The problem with that is that 'true' would no longer just be a simple constant. It would be a constant some of the times (like func(5,true)), but other times (when comparing), it would be something entirely different. It wouldn't have a value; it'd be something of a construct in and of itself. Or rather, '==true' would be a construct, as without the '==', it wouldn't work the same way.
Aug 31 2005
parent Derek Parnell <derek psych.ward> writes:
On Wed, 31 Aug 2005 08:58:07 -0400, Jarrett Billingsley wrote:

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:jag0mz602hw$.u59i5vti46wf$.dlg 40tude.net...
 Would it be useful if the compiler saw '<expression> == true' as
 '<expression> != 0'?

 Then these would be equivalent ...

   if (Fld) ...

 and

   if (Fld == true) ...

 because currently these are not equivalent.

I'm not sure if you're looking for utility or for syntactic sugar ;) The problem with that is that 'true' would no longer just be a simple constant. It would be a constant some of the times (like func(5,true)), but other times (when comparing), it would be something entirely different. It wouldn't have a value; it'd be something of a construct in and of itself. Or rather, '==true' would be a construct, as without the '==', it wouldn't work the same way.

Umm, yeah ... so where's the problem? When people write "if (X == true)" I assume they want to know if X contains one of the many values that D regards as a truth value. If they want to see if X contains the value 1, they would write "if (X == 1)". So in this regards, the syntax "EXPR == true" *is* a construct. Why I even raised this is that I tripped over this today ... if (isalpha(X) == true) as it was only 'working' for upper case alphas. Lowercase alphas returned 2 and not 1. This is because isalpha is defined as int isalpha(dchar c) { return (c <= 0x7F) ? _ctype[c] & (_ALP) : 0; } where _ALP has the value 3. My assumption was that functions named "is..." would return a true/false value (yeah, I know ... RTFM; but what manual?). In other words I assumed it was coded as ... bool isalpha(dchar c){return (c<=0x7F)&&(_ctype[c]&(_ALP)) ? true:false);} My bad I know, but then I got to thinking that I wish the compiler could recognize the HINT that I was after truth and not a numeric comparison. -- Derek Parnell Melbourne, Australia 31/08/2005 11:15:56 PM
Aug 31 2005
prev sibling next sibling parent reply Shammah Chancellor <Shammah_member pathlink.com> writes:
In article <jag0mz602hw$.u59i5vti46wf$.dlg 40tude.net>, Derek Parnell says...
Would it be useful if the compiler saw '<expression> == true' as
'<expression> != 0'? 

Then these would be equivalent ...

   if (Fld) ...

and

   if (Fld == true) ...

because currently these are not equivalent.

import std.stdio;
int main()
{
    int A = 2;

    if (A) writefln("A");
    if (A!=0) writefln("A!=0");
    if (A==true) writefln("A==true");

    return 0;
}

Is truth the complement of falsehood? Who defines truth as anything which is not false? -Sha
Aug 31 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 31 Aug 2005 14:13:42 +0000 (UTC), Shammah Chancellor wrote:

 In article <jag0mz602hw$.u59i5vti46wf$.dlg 40tude.net>, Derek Parnell says...
Would it be useful if the compiler saw '<expression> == true' as
'<expression> != 0'? 


[snip]
 Is truth the complement of falsehood?   Who defines truth as anything which is
 not false?

Ummm... me? I kinda feel that an assertion is either true or false but not both at the same time. It cannot be neither, although we may not know which it is at any given instant. But now we getting all philosophical and off topic ;-) -- Derek Parnell Melbourne, Australia 1/09/2005 7:30:44 AM
Aug 31 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <1vyjlspt3ayjp.i722adx36thy.dlg 40tude.net>, Derek Parnell says...
On Wed, 31 Aug 2005 14:13:42 +0000 (UTC), Shammah Chancellor wrote:

 Is truth the complement of falsehood?   Who defines truth as anything which is
 not false?

Ummm... me? I kinda feel that an assertion is either true or false but not both at the same time. It cannot be neither, although we may not know which it is at any given instant. But now we getting all philosophical and off topic ;-)

Quantum states make things even more intersting ;-) The answer to this seems to go back to the old argument about whether bit is a numeric or logical type. If bit is numeric then current behavior makes perfect sense, but the constants 'true' and 'false' are quite misleading. Otherwise, I agree that the behavior must change. Sean
Aug 31 2005
parent reply Shammah CHancellor <Shammah_member pathlink.com> writes:
In article <df5986$2k8h$1 digitaldaemon.com>, Sean Kelly says...
In article <1vyjlspt3ayjp.i722adx36thy.dlg 40tude.net>, Derek Parnell says...
On Wed, 31 Aug 2005 14:13:42 +0000 (UTC), Shammah Chancellor wrote:

 Is truth the complement of falsehood?   Who defines truth as anything which is
 not false?

Ummm... me? I kinda feel that an assertion is either true or false but not both at the same time. It cannot be neither, although we may not know which it is at any given instant. But now we getting all philosophical and off topic ;-)

Quantum states make things even more intersting ;-) The answer to this seems to go back to the old argument about whether bit is a numeric or logical type. If bit is numeric then current behavior makes perfect sense, but the constants 'true' and 'false' are quite misleading. Otherwise, I agree that the behavior must change. Sean

Bit is a numeric type, bool is a logical type. Bool should be seperate as another thread was arguing. The behavior of bit should not be changed. Also, I find it funny that the person who posted this: Nothing, except that ends() return an integer (-1) if it fails, and the compiler doesn't bother to mention that it's implicitly converting the bool (true) to an integer. Not even if -w is operating. Is now posting this: Would it be useful if the compiler saw '<expression> == true' as '<expression> != 0'? <snip> if (A) writefln("A"); if (A!=0) writefln("A!=0"); if (A==true) writefln("A==true"); <snip> Why are you, who seemed to be opposed of conversions from ints to bool (which i agree with.) now upset that A==true returns false when A is the integer 2?????????!?!?!?!?! According to your previous statements it should throw an exception or be a compiler error!!! Not to mention the whole proposition is silly considering MOST of the time when you're checking for trueness or falseness against an integer, ZERO is true, and anything else represents how false the comparision is. IE: strcmp() == false <-- would return true when strcmp is true, this code is wrong. strcmp() == true <-- returns true when strcmp happens to return 1, the strings are unequal. still wrong code. Even with == true being rewritten as != 0 being "truth" this would still give the wrong answer. -Sha
Aug 31 2005
next sibling parent Derek Parnell <derek psych.ward> writes:
On Thu, 1 Sep 2005 00:23:32 +0000 (UTC), Shammah CHancellor wrote:

 In article <df5986$2k8h$1 digitaldaemon.com>, Sean Kelly says...
In article <1vyjlspt3ayjp.i722adx36thy.dlg 40tude.net>, Derek Parnell says...
On Wed, 31 Aug 2005 14:13:42 +0000 (UTC), Shammah Chancellor wrote:

 Is truth the complement of falsehood?   Who defines truth as anything which is
 not false?

Ummm... me? I kinda feel that an assertion is either true or false but not both at the same time. It cannot be neither, although we may not know which it is at any given instant. But now we getting all philosophical and off topic ;-)

Quantum states make things even more intersting ;-) The answer to this seems to go back to the old argument about whether bit is a numeric or logical type. If bit is numeric then current behavior makes perfect sense, but the constants 'true' and 'false' are quite misleading. Otherwise, I agree that the behavior must change. Sean

Bit is a numeric type, bool is a logical type. Bool should be seperate as another thread was arguing. The behavior of bit should not be changed.

In theory, I totally, 110%, agree with that position.
 Also, I find it funny that the person who posted this:

 Nothing, except that ends() return an integer (-1) if it fails, and the
 compiler doesn't bother to mention that it's implicitly converting the bool
 (true) to an integer. Not even if -w is operating.

But in practice, nothing is ever going to change Walters mind, so I'm trying to go with the flow (and just between you and me, maybe we can sneak up on Walter and change his stance by stealth; but keep that a secret, okay?) and thus minimize wasted efforts.
 Is now posting this:
 
 Would it be useful if the compiler saw '<expression> == true' as
 '<expression> != 0'? 

It's called "waiting for the right time to pick a fight" ;-)
 Why are you, who seemed to be opposed of conversions from ints to bool (which i
 agree with.) now 
 upset that A==true returns false when A is the integer 2?????????!?!?!?!?!
 According to your previous 
 statements it should throw an exception or be a compiler error!!!

But occasionally I'm a practical person. So I'm letting this one slip by and asking for it in a different (and admittedly piecemeal) way.
 Not to mention the whole proposition is silly considering MOST of the time when
 you're checking for 
 trueness or falseness against an integer, ZERO is true, and anything else
 represents how false the 
 comparision is.
 
 IE:  strcmp() == false <-- would return true when strcmp is true, this code is
 wrong. 
 strcmp() == true <-- returns true when strcmp happens to return 1, the strings
 are unequal. still 
 wrong code.  Even with == true being rewritten as != 0 being "truth" this would
 still give the wrong 
 answer.

But the function isn't named "isstrequal" so I'm not expecting an either/or return value. From my assembler experience, I'm quite used to the cmp instruction and then testing for any number of results; jeq, jne, jgt, jlt, jge, jle. If we had a function called "isequal(char[] A, char[] B)" then I would expect that function to return a yes/no response. That's why I took our colleague's advice and changed my 'ends()' function to return a yes/no value - because it reads better that way. -- Derek (skype: derek.j.parnell) Melbourne, Australia 1/09/2005 10:26:32 AM
Aug 31 2005
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Shammah CHancellor wrote:

 Bit is a numeric type, bool is a logical type.
 Bool should be seperate as another thread was arguing.  
 The behavior of bit should not be changed.

* me wakes up, wonder if anything happened to D * - "oh no, not that same old tired discussion again" * goes back to sleep, dreaming of something else * --anders PS. Here was my old attempt to make lemonade out of it: http://www.prowiki.org/wiki4d/wiki.cgi?BitsAndBools
Sep 01 2005
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:jag0mz602hw$.u59i5vti46wf$.dlg 40tude.net...
 Would it be useful if the compiler saw '<expression> == true' as
 '<expression> != 0'?

Or one could change the implicit conversion rules "usual arithmetic conversions" described on http://www.digitalmars.com/d/type.html to say that if one of the two types is "bit" that the other type is converted to bit. This would be rule 4a - between the float conversions and the integer promotions. Then <expr> == true would have the behavior you expect.
Aug 31 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 31 Aug 2005 14:46:29 -0400, Ben Hinkle wrote:

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:jag0mz602hw$.u59i5vti46wf$.dlg 40tude.net...
 Would it be useful if the compiler saw '<expression> == true' as
 '<expression> != 0'?

Or one could change the implicit conversion rules "usual arithmetic conversions" described on http://www.digitalmars.com/d/type.html to say that if one of the two types is "bit" that the other type is converted to bit. This would be rule 4a - between the float conversions and the integer promotions. Then <expr> == true would have the behavior you expect.

Yep, that would do it too. -- Derek Parnell Melbourne, Australia 1/09/2005 7:30:06 AM
Aug 31 2005
parent reply Shammah Chancellor <Shammah_member pathlink.com> writes:
In article <1xfwna3ygghr4.vv7m5z2cm8rt.dlg 40tude.net>, Derek Parnell says...
On Wed, 31 Aug 2005 14:46:29 -0400, Ben Hinkle wrote:

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:jag0mz602hw$.u59i5vti46wf$.dlg 40tude.net...
 Would it be useful if the compiler saw '<expression> == true' as
 '<expression> != 0'?

Or one could change the implicit conversion rules "usual arithmetic conversions" described on http://www.digitalmars.com/d/type.html to say that if one of the two types is "bit" that the other type is converted to bit. This would be rule 4a - between the float conversions and the integer promotions. Then <expr> == true would have the behavior you expect.

Yep, that would do it too.

This is rediculous. Bit should be consistent with int and any other numeric type. Bool should be a separate type as another thread was stating. Converting any other type to bit when the number is greater than 1 would not result in the expected behavior, but instead an overflow. It should throw an exception. Why would a comparision for bit demote the larger type? Everywhere else where numbers are promoted! (To prevent overflows when comparing long to int!) -Sha
Aug 31 2005
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Shammah Chancellor" <Shammah_member pathlink.com> wrote in message 
news:df5gjh$2rbk$1 digitaldaemon.com...
 In article <1xfwna3ygghr4.vv7m5z2cm8rt.dlg 40tude.net>, Derek Parnell 
 says...
On Wed, 31 Aug 2005 14:46:29 -0400, Ben Hinkle wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:jag0mz602hw$.u59i5vti46wf$.dlg 40tude.net...
 Would it be useful if the compiler saw '<expression> == true' as
 '<expression> != 0'?

Or one could change the implicit conversion rules "usual arithmetic conversions" described on http://www.digitalmars.com/d/type.html to say that if one of the two types is "bit" that the other type is converted to bit. This would be rule 4a - between the float conversions and the integer promotions. Then <expr> == true would have the behavior you expect.

Yep, that would do it too.

This is rediculous. Bit should be consistent with int and any other numeric type. Bool should be a separate type as another thread was stating.

Search the newsgroups for bit vs bool related threads to get the background on bits and bools. It was a hot topic a while ago but hasn't flared up lately.
 Converting any other type to bit when the number is
 greater than 1 would not result in the expected behavior, but instead an
 overflow. It should throw an exception.

Throwing an exception on a numeric conversion would be bad. Converting integer values x that != 0 to true is the desired behavior since it then matches the expression x?true:false.
 Why would a comparision for bit demote the larger type? Everywhere else 
 where
 numbers are promoted!
 (To prevent overflows when comparing long to int!)

The only useful binary ops involving bit and some other integer type are things that result in bits. Wacky code that really wants bits treated like the ints 0 and 1 (like x*flag for a bit valued flag) can cast the bit to an int. The mental model of integer ranges like int, long etc does not apply to bits since there's only two values 0/1 not a range of values like 0 to 255 and no-one should be doing range-based arithmetic on bits.
Sep 01 2005
prev sibling parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Derek Parnell wrote:
 Would it be useful if the compiler saw '<expression> == true' as
 '<expression> != 0'? 
 

problem! However your alternative is incorrect just as that, as it is incomplete: one has to consider the general case of '<int/long expression> == <bool expression>' (and vice-versa), not just with true. For instance as in this: ( isAlpha('c') == returnsTrue() ) So, as for '<int/long expression> == <bool expression>', in my opinion, it should either work as you expect (do a boolean compare), or it should be illegal (compile error). That isAlpha() bug was really nasty! -- Bruno Medeiros Computer Science/Engineering student
Aug 31 2005