[Tcl-bugs] [ tcl-Bugs-3588512 ] expr { ( ! true ) == false }

[SourceForge.net <no...@so...>]

Bugs item #3588512, was opened at 2012-11-19 07:13
Message generated for change (Comment added) made by heinrichmartin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3588512&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 47. Bytecode Compiler
Group: development: 8.6.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: heinrichmartin (heinrichmartin)
Assigned to: Don Porter (dgp)
Summary: expr { ( ! true ) == false }

Initial Comment:
OS: Debian Squeeze

Promblem: expr is not consistent with boolean values and operators, i.e. [expr { ( ! true ) == false }] yields 0

Expected: "not true" is logically the same as "false" - expr should know that.

A few notes:
* tested in tclsh 8.5
* found no bugs for "expr" in current and developement
* a fix could break existing code (that's why I put it in group developement)
* workaround: always use bool() or !! for explicit conversion, i.e. [expr { ( ! true ) == bool ( false ) }] yields 1

----------------------------------------------------------------------

>Comment By: heinrichmartin (heinrichmartin)
Date: 2012-11-19 23:15

Message:
well, then the documentation is wrong - or at least misleading.

expr (==,!=): "Boolean equal and not equal. Each operator produces a
zero/one result. Valid for all operand types."

btw. why are "expr" and "if" in different bug categories??

another suggestion: is it useful to distinguish '0==false' (1) and
'0=="false"' (0)? the parser knows about the boolean meaning of false -
otherwise it would raise an invalid bareword exception! So, why is tcl
using the string representation of false?

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2012-11-19 14:21

Message:
Part of the problem is that == isn't really the type of equality you're
after; it does _numeric_ equalty and (when that's not type-compatible)
otherwise string equality. Alas, '0==false' doesn't fit in that scheme too
nicely.

This might need to be a FRQ…

----------------------------------------------------------------------

Comment By: Serg G. Brester (sebres)
Date: 2012-11-19 09:36

Message:
This happens because "false" is not the same as boolean "0" (cause of
saving it string representation):
% expr { false } 
false
% expr { (! true) } 
0
So this code is true
% expr { (! true) == 0 } 
1

But in something you're right - it is not really consistent, cause:
% expr { false == false }
1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3588512&group_id=10894