"=" or "==", I don't understand...

[guinness]

Spiff59,

I hope you can understand that I'm happy to change something that is wrong in the help, but I won't be doing so until you either point me to the right direction of this thread you talk about and/or clarify your wording.

You said you've been trying to get this changed for 4 years, so now is your chance.

[Spiff59]

That's the difficult part: concisely describing the behavior.

This demonstrates what is taking place:

If Chr(0) = "" Then Beep(900,100) ; --> true
sleep(50)
If 0 = "" Then Beep(900,100) ; --> true
sleep(50)
If 0 = Chr(0) Then Beep(900,100) ; --> true
sleep(50)
If 0 = "0" Then Beep(900,100) ; --> true
sleep(50)
If 0 = False Then Beep(900,100) ; --> true

sleep(500)

If Chr(0) == "" Then Beep(900,100) ; --> false
sleep(50)
If 0 == "" Then Beep(900,100) ; --> false
sleep(50)
If 0 == Chr(0) Then Beep(900,100) ; --> false
sleep(50)
If 0 == "0" Then Beep(900,100) ; --> true
sleep(50)
If 0 == False Then Beep(900,100) ; --> false
sleep(50)
If "False" == False  Then Beep(900,100) ; --> true!
sleep(50)
$var = 666
If "$var" == $var  Then Beep(900,100) ; --> false

The general rule seems to be that the "=" operator will convert any string or boolean to a numeric value prior to the compare, and the "==" operator only converts numerics to strings before testing. Oddly, as in the demo, the "==" operator treats a boolean as the string value of it's token/keyword, so 0 or 1 never equal either TRUE ot FALSE. That behavior, not resolving the token down to some value almost seems a bug. How to describe it, I dunno. Other exception to the general rule makes thing even muddier. Can we say that "==", with the exception of strings and numerics, requires the operands to be of the same type? What types are a Chr(0) or a "" to be considered? Are they being converted, failing conversion, or being ignored?

The most practical reason for using "==" (along with testing case) is that "==" discerns between 0, Chr(0) and "", the "=" operator does not. That is not in the helpfile. How to more fully describe the rules and simultaneously make them more understandable might best be a group decision. Rather than stemming the regular flow of posts regarding the helpfile and these operands, a modified helpfile entry that is not well-conceived could make things worse.

[guinness]

It's certainly a tricky one. I would have used MsgBox or ConsoleWrite instead of Beep to demonstrate.

[AZJIO]

Spiff59,

MsgBox(0, 'This is 0', Binary(Chr(0))&@CRLF& Hex(Chr(0)))

Edited February 12, 2013 by AZJIO

[jchd]

@Spiff59,

Read a few posts in the thread pointed to by AZJIO. Read the relevant parts of the help file again. You can use the function below to tell which type is what and with conversion rules in mind + semantics of the = and == operators, the mud should clear and all of your questions should get answered.

expandcollapse popup

Func _VarDump(ByRef $vVar, $sIndent = '')
    Local $ret, $len
    Select
        Case IsDllStruct($vVar)
            $len = DllStructGetSize($vVar)
            Local $bstruct = DllStructCreate("byte[" & $len & "]", DllStructGetPtr($vVar))
            $ret = 'Struct(' & $len & ') @:' & Hex(DllStructGetPtr($vVar)) & ' = '
            If $len <= 32 Then
                Return($ret & DllStructGetData($bstruct, 1))
            Else
                Return($ret & BinaryMid(DllStructGetData($bstruct, 1), 1, 16) & ' ... ' & StringTrimLeft(BinaryMid(DllStructGetData($bstruct, 1), $len - 15, 16), 2))
            EndIf
        Case IsArray($vVar)
            Local $iSubscripts = UBound($vVar, 0)
            Local $sDims = 'Array'
            $iSubscripts -= 1
            For $i = 0 To $iSubscripts
                $sDims &= '[' & UBound($vVar, $i + 1) & ']'
            Next
            Return $sDims & @CRLF & _VarDumpArray($vVar, $sIndent)
        Case IsBinary($vVar)
            $len = BinaryLen($vVar)
            $ret = 'Binary(' & BinaryLen($vVar) & ') = '
            If $len <= 32 Then
                Return($ret & $vVar)
            Else
                Return($ret & BinaryMid($vVar, 1, 16) & ' ... ' & StringTrimLeft(BinaryMid($vVar, $len - 15, 16), 2))
            EndIf
        Case IsBool($vVar)
            Return 'Boolean ' & $vVar
        Case IsFloat($vVar) Or (IsInt($vVar) And VarGetType($vVar) = "Double")
            Return 'Double ' & $vVar
        Case IsHWnd($vVar)
            Return 'HWnd ' & $vVar
        Case IsInt($vVar)
            Return "Integer(" & StringRight(VarGetType($vVar), 2) & ') ' & $vVar
        Case IsKeyword($vVar)
            $ret = 'Keyword '
            If $vVar = Null Then
            Return $ret & 'Null'
        Else
            Return $ret & $vVar
        EndIf
        Case IsPtr($vVar)
            Return 'Pointer @:' & StringTrimLeft($vVar, 2)
        Case IsObj($vVar)
            Return 'Object ' & ObjName($vVar)
        Case IsString($vVar)
            $len = StringLen($vVar)
            $ret = 'String(' & $len & ") "
            If StringRegExp($vVar, "[\x00-\x1F\x7F-\x9F]") Then
                If $len <= 64 Then
                    Return $ret & _DumpStringWithControlChars($vVar)
                Else
                    Return($ret & StringMid(_DumpStringWithControlChars($vVar), 1, 32) & ' ... ' & StringTrimLeft(StringMid(_DumpStringWithControlChars($vVar), $len - 31, 32), 2))
                EndIf
            Else
                If $len <= 64 Then
                    Return $ret & "'" & $vVar & "'"
                Else
                    Return($ret & "'" & StringMid($vVar, 1, 32) & ' ... ' & StringTrimLeft(StringMid($vVar, $len - 31, 32), 2)) & "'"
                EndIf
            EndIf
        Case Else
            Return 'Unknown ' & $vVar
    EndSelect
EndFunc

Func _VarDumpArray(ByRef $aArray, $sIndent = @TAB)
    Local $sDump
    Local $sArrayFetch, $sArrayRead, $bDone
    Local $iSubscripts = UBound($aArray, 0)
    Local $aUBounds[$iSubscripts]
    Local $aCounts[$iSubscripts]
    $iSubscripts -= 1
    For $i = 0 To $iSubscripts
        $aUBounds[$i] = UBound($aArray, $i + 1) - 1
        $aCounts[$i] = 0
    Next
    $sIndent &= @TAB
    While 1
        $bDone = True
        $sArrayFetch = ''
        For $i = 0 To $iSubscripts
            $sArrayFetch &= '[' & $aCounts[$i] & ']'
            If $aCounts[$i] < $aUBounds[$i] Then $bDone = False
        Next

        $sArrayRead = Execute('$aArray' & $sArrayFetch)
        If @error Then
            ExitLoop
        Else
            $sDump &= $sIndent & $sArrayFetch & ' => ' & _VarDump($sArrayRead, $sIndent)
            If Not $bDone Then
                $sDump &= @CRLF
            Else
                Return $sDump
            EndIf
        EndIf

        For $i = $iSubscripts To 0 Step -1
            $aCounts[$i] += 1
            If $aCounts[$i] > $aUBounds[$i] Then
                $aCounts[$i] = 0
            Else
                ExitLoop
            EndIf
        Next
    WEnd
EndFunc


Func _DumpStringWithControlChars(ByRef $sStr)
    Local $sDump
    Local $aCh = StringToASCIIArray($sStr)
    Local $bInStr = False
    For $ch In $aCh
        Switch $ch
            Case 0 To 0x1F, 0x7F To 0x9F
                If $bInStr Then
                    $bInStr = False
                    $sDump &= "'"
                EndIf
                $sDump &= " 0x" & Hex($ch, 2) & " "
            Case Else
                If Not $bInStr Then
                    $bInStr = True
                    $sDump &= "'"
                EndIf
                $sDump &= ChrW($ch)
        EndSwitch
    Next
    If $bInStr Then $sDump &= "'"
    Return($sDump)
EndFunc

Sample usage:

Local $Vars[7] = [ '', 0, 0.0, Chr(0), False, Null, 'abc' & @TAB & 'def' ]
For $Var In $Vars
ConsoleWrite(_VarDump($Var) & @LF)
Next

[Spiff59]

Those links both specifically refer to documenting the "=" operand.

My entire post above, except for a single sentence, is regarding the "==" operator.

The behavior of the "=" operator has never seemed a cause of much ambiguity.

...with conversion rules in mind + semantics of the = and == operators, the mud should clear and all of your questions should get answered.

The only question I've had for a few years is how can the "==" operator be better documented. I don't think expecting newcomers to study internal data storage architecture, or to be able to glance at a routine like _VarDump() without pooping their pants, is realistic. Leaving the helpfile as-is will not reduce the occurance of forum threads with titles similar to this thread. The helpfile fails to describe functionally the behavior of the "==" operator. The last sentence of the "==" entry denies one of it's most valuable uses (differentiating between 0, "0", Chr(0), "", and False). I think the entry should try to simply state from a usage standpoint how the operator behaves, and not delve too much into data conversions or concepts likely to send people straight to the forum to exclaim "Say what?".

[jchd]

While I understand your point, I don't believe it's possible to satisfy the actual internal specification of == AND at the same time precisely describe its behavior without discussing every possible type mix. Doing the latter would go far beyond the currently published spec of == i.e. that it's only to be used on strings.

That == currently CAN be used for comparing other types doesn't mean it is internally intended to keep on behaving the way we can see now. I agree that this point of view is a devil's advocate but OTOH if devs really wanted == to be used accross every type and behave in a constant and consistent manner, they probably would have said so and documented it. I also agree that changing the behavior now is likely to break many scripts around but we have little guaranties on that.

The dynamic typing AutoIt uses thru variants has both advantages and drawbacks. It's the user's responsability to code defensively against undocumented features (conversions or whatever) that may not last forever. In most cases, AutoIt applies internal smart conversions which make coding easy and unsurprising in most uses, but not all.

If you don't trace yourself which types are your own variables in your own code, you can still either convert explicitely or use VarGetType or Is* functions.

[Spiff59]

This operator has behaved this way for years, and being unaware of anyone having any intention of changing it, it's likely to still perform the same way years from now.

I think it's more appropriate to document what the operator actually does, rather than an impression of how it was intended to behave.

[jchd]

You don't seem to differentiate between specification and implementation details (= bugs, undocumented features, side-effects, ...).

A specification describes the guaranted built-in behavior. How something dances in situations not covered by the specification IS an implementation detail subject to change without notice.

Documenting implementation details amounts to force new specifications to the development team against their will.

I agree the documentation about == might be made more explicit, but this is a development team decision, not a doc maintainer decision.

A seemingly unrelated example comes to my mind: the various SQL standard don't make any statement about the order of rows in the output of a SELECT unless an explicit ORDER BY clause is used. That order and its stability are unspecified.

Yet most engines will produce rows in the "user-expected" order and in a stable manner. Anyway, an SQL-compliant engine is allowed to produce rows in any order and even exhibit a different random order on two successive runs of the same SELECT, still without breaking compliance.

The mention of a stable "expectable" order in the doc of an engine -just because it works that way currently- would force developpers to live with that extra specification, which might prevent the implementation of a new caching scheme capable of gaining 30% efficiency, for instance. That always means extra code to ensure satisfaction of the new spec in all cases, more potential bugs, more testing, more time and less flexibility towards future improvements.

[AZJIO]

jchd

I agree the documentation about == might be made more explicit, but this is a development team decision, not a doc maintainer decision.

If not documented by one person, forcing thousands of users define behaviors. In this case, the documented behavior of ==. While not everyone knows what a lexicographical order. This forces to read in Google.

[BrewManNH]

The help file isn't a dictionary, it's a help file. There could be a glossary in the Appendix section with a brief description of certain words, but there isn't one in this file.

An undocumented feature is just that, it is supposed to work "this way", but in reality it works "that way" but it's not guaranteed to continue working "that way". If you use something in a way that is not like it's described in the documentation, there's a possibility that it will stop working like that in the future.

[AZJIO]

BrewManNH,

possibility that it will stop working like that in the future.

I expected this answer. In the future you can change and documentation too. Intention to hide because it can be changed isn't correct.

[jchd]

That would need testing everything that you document --without acknowledgement of the development team-- for every release, every possible user context, every OS and every OS change ... It's plain impossible.

Documenting == now is heretic since we, mere users, don't have the faintest idea on WHY == works like that: all you can write about that is only wild guess.

Maybe it's because of the side-effect of a long lasting bug which relies on traces left on the internal stack, maybe it's because of a little memory chunk which is freed too late, maybe it's because a certain flag (carry, overflow, whatever) is raised by chance by some system call, maybe it's "just this way" because the devs didn't properly check that input parameters are of the expected type or made their method inherits from a too broad class, maybe a lucky buffer overflow, ...

ANY change can break the behavior you see now: devs using a new compiler, a new compiler switch, a completely unrelated code change, any Windows Update anytime, anything as you don't know why == works the way we guess it works. Again I agree that all the causes I enumerated above are rather unlikely but the truth is that neither you or me or nobody else except devs know why things are the way we note.

Documenting == fully would require deep internal knowledge about how it behaves in all cases. Even today, are you 100% sure of how it works when comparing COM objects against every type? Two instances of some COM objects initialized identically will they be equal based on their content or address or what?

Suppose new development in AutoIt offer new types (e.g. tables, objects and functions as first-class citizens, ...) will you keep on gambling on what happens internally with them?

All we can do is post here that we suppose that == generally behaves this way, without any garanty. Promoting that in the help file is just gambling with every user's money.

[Spiff59]

I kind of doubt whether any official specification exists for the == operator? Was it introduced in v2? How much later was the helpfile developed?

Looking back, I do see within weeks of my first griping about the documentation in early 2009 that Valik submitted bugtracker #886 stating that the == documentation should not say the only difference between = and == was case-sensitivity, that it needs to state that == converts both operands to strings. He does not elaborate on what that implies, although he obviously felt it an important point.

So, maybe what we're seeing is entirely within specifications. That converting values like "" and FALSE and Chr(0) to a string that will not match 0 or "0" (as they do with the = operator) is the expected result of string conversions. If this behavior is within the specifications for both the == operator and string conversions, then maybe the documentation ought to say that == is case sensitive, converts both operands to string, and as a result is useful for distinguishing between 0, a null string, the NUL character, and boolean FALSE? At the least, the recently added line of text stating "This operator should only be used for string comparisons that need to be case sensitive." should get the axe.

[jchd]

I can witness from lengthy discussion with Valik long time ago that comparison operators have been their internal method changed.

Now I'm not in the position to formally advise about their new garanteed behavior. In the case you have various types and are unsure about how it works, you can still rely on documented language elements to achieve your goal:

If $myvar = 0 Then
    Switch VarGetType($MyVar)
        Case ...
        ...
    EndSwitch
EnfIf

[AZJIO]

Spiff59

If this behavior is within the specifications for both the == operator and string conversions, then maybe the documentation ought to say that == is case sensitive, converts both operands to string

This is already stated in the documentation.

and as a result is useful for distinguishing between 0, a null string, the NUL character, and boolean FALSE?

You determine useful for you or not. It does not need the documentation.

[Spiff59]

As any aspect of AUtoIT may someday change, it all exists in a dynamic state of flux, so why have any documentation at all?

This is already stated in the documentation.

You determine useful for you or not. It does not need the documentation.

I'm quite aware of what is, and is not, in the documentation, Had I stated it should read "useful for distinguishing between 0, a null string, the NUL character, and boolean FALSE?", you might now be informing me that I'd neglected to state it was "case sensitive, and converts both operands to strings".

After thinking about Valik's BugTracker, I found a new outlook on this issue. It is the behavior of string conversions on exceptional data types like nulls or booleans, that gives == it's characteristics. He insisted that it be documented as not "only being case-sensitive" when compared to =, but that it converting operands to strings must also be noted. What is implied by that? Why is "case-sensitive" not enough? There are likely only a handful who can glance at the sentence Valik added and know the ramifications. It requires a knowledge of exotic data conversions within AutoIT. That does nothing to enlighten us less-ethereal types, nor does it stem the flow of new forum threads.

Last thoughts...

Documentation ought to describe actual behavior, not desired behavior.

The sentence recently added to the end of the documentation nullifies the entire point of Valik's addition and you might as well revert that.

I won't respond to future threads on this topic. I'm sure others will respond to them, apparently in some cases referring someone with a single-digit post count to brush-up on data types, internal storage and conversion specifications.

Edited February 14, 2013 by Spiff59