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'? 
 


I saw your isAlpha() snippet and I do agree that is quite a language 
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