Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#5131 expr { ( ! true ) == false }

current: 8.6.0
open
Don Porter
5
2012-11-19
2012-11-19
heinrichmartin
No

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

Discussion

  • 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

     
    • labels: --> 47. Bytecode Compiler
    • assigned_to: nobody --> dgp
     
  • 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…

     
  • heinrichmartin
    heinrichmartin
    2012-11-20

    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?