AutoIt v3.3.13.11 Beta

[guinness]

I thought you meant the value of default, not the value of Default - True. I don't think -0.5 as a result would make sense since AutoIt internally see a mathematical expression and converts both keywords to their integer values.

[czardas]

I don't think anything other than NaN would make sense. This seems a contradiction:

Earlier versions:

ConsoleWrite((Default + True = False) & @LF) ; ==> True
ConsoleWrite((False - True = Default) & @LF) ; ==> False

I find that rather uncomfortable and inconvenient. A float would negate this inconsistancy to a limited degree, but I still wouldn't like it. Defaulting (the keyword Default) to a value of zero also seems fraught with complications - I think it's better to revert back, even if it isn't ideal.

Edited July 28, 2014 by czardas

[jchd]

Conversions of the Keywords to numeric is inconsistent in type and at time self-contradictory in value:

Local $a = [ _
    "Null", _
    "Default", _
    "False", _
    "True" _
]
Local $b = [ _
    "Number(#)", _
    "Int(#)", _
    "# + 0", _
    "0 + #", _
    "# * 1", _
    "1 * #", _
    "# ^ 1", _
    "# + #", _
    "# - #", _
    "# * #", _
    "# / 1" _
]
Local $r, $s
For $s1 In $a
    ConsoleWrite("Processing " & VarGetType(Execute($s1)) & " " & $s1 & @LF)
    For $s2 In $b
        $s = StringReplace($s2, "#", $s1)
        $r = Execute($s)
        ConsoleWrite(StringFormat("%18s\t%s\t= %s\n", $s, VarGetType($r), ($r = Null ? "Null" : $r)))
    Next
    ConsoleWrite(@LF)
Next

Edited July 28, 2014 by jchd

[TypeIt]

I don't think anything other than NaN would make sense.

I don't think that anything should be assumed when reinterpreting keywords as numbers. I don't think that they should be used in numeric expressions.

[Mat]

I don't think that anything should be assumed when reinterpreting keywords as numbers. I don't think that they should be used in numeric expressions.

Agreed.

However, AutoIt does have a variant system whose strength lies in the fact that it's very tolerant of people doing all kinds of crazy things. (Like ConsoleWrite($aAnArray & "A String") for example)

Also, some keywords can be safely converted to a number. Null -> zero, True -> 1, False -> 0 are all fairly standard results, and are consistent with the behaviour of the keywords. Default is a odd case, which historically was meant to replace the -1 used as a default value in many functions. 

[jaberwacky]

Found the regression, and also an improvement, so the next beta will be faster than stable.

I don't see the problem with this code.  How were you able to even tell what was being pointed out?

[czardas]

I don't think that anything should be assumed when reinterpreting keywords as numbers. I don't think that they should be used in numeric expressions.

 

I disagree: one can assume certain codes of behaviour from past experience. The Default keyword is intended to be used as a function parameter, and False is frequently assigned as a default value for other parameters in AutoIt. Setting False and Default both equal to zero (when they are converted to integers) seems potentially problematic.

Also I can think of valid reasons to use these keywords in mathematical expressions - although I totally accept that it is an off-beat concept. I was also once considering a suggestion made to me: to use the Default keyword as a third 'undefined' boolean state. At the time I never took up  the idea, but now this functionality may be compromised.

Additionally, -1 is the default value for many functions, such as the last control created; although I often write the number, the following syntax looked fine to me actually. I admit I haven't tested it (maybe it somehow still works).

;

GUICtrlSetState(Default, $GUI_DISABLE)

;

I would like to understand the justification when core values need to be altered. If the Default keyword should default to False, to comply with some globally accepted standard, then perhaps such a change is warranted. It still seems to be rather a big decision to make.

Edited July 28, 2014 by czardas

[BrewManNH]

Unless the keyword is intended to be used in a mathematical equation using one that way is a bad way to code. Default, for as long as I can remember, has always equated to -1, which is probably why using -1 to identify the last created GUI/Control always worked even before it was documented.

[czardas]

What's this, the code police? Anyway; bad ways to code can be acceptable, but only under the condition that it is intentional and for a valid reason. Obfuscation would be one valid and justified reason to do such things. This is not good criteria to define keyword values, but modifications to such are still undesirable.

It is arbitrary to some degree. In my three value logic code, I set 'True' equal to 2 and 'Undefined' equal to 1. I could have set 'Undefined' equal to 0 and 'False' equal to -1 instead. That would have been conceptually simpler, but unfortunately more difficult to implement.

Edited July 29, 2014 by czardas

[jchd]

Departing from the widely used (in and far outside the AutoIt world) convention that False converts to 0 and True converts to "not 0" (and often 1) would be uselessly problematic for both existing code base and newcomers.

OTOH a solid design choice could have been to use the three-value logic (3VL)  in use in SQL. Since Null can translate into "no data present" (but that statement doesn't hold in all 32VLs) it shouldn't make sense to accept conversion to any real-world value in any case.

Other 3VLs exist but are much less in use in programming. Of course the added bonus is that Null behavior would have been 100% consistent with every SQL engine and there is a number of users for which this can be important in practice. An important consequence of this choice is that Null <> Null and If $n = Null is Null if $n is Null but this is alleviated in SQL with IsNull and IsNotNull.

The case of Default is different. Its current forced conversion to numeric using Int() or Number() are inconsistent (give 0) with its behavior in implicit conversions (giving -1). The best would have been to make Default a similar keyword to Null and never accept to convert it to any value in any context.

Again IsDefault and IsNotDefault would then be useful instead of the infamous return value of IsKeyword.

Unfortunately these conventions would break the fundamental paradigm in AutoIt that its variants auto-convert depending on context. On the other side we would no more see things like:

Func _myFunc($arg = $MY_LOVELY_CONSTANT)
    If IsKeyword($arg) = 1 Or $arg = -1 Or $arg = "" Then $arg = $MY_LOVELY_CONSTANT
    ...

Edited July 29, 2014 by jchd

[czardas]

Departing from the widely used (in and far outside the AutoIt world) convention that False converts to 0 and True converts to "not 0" (and often 1) would be uselessly problematic for both existing code base and newcomers.

 

This was a consideration when I decided to retain the value False = 0.

OTOH a solid design choice could have been to use the three-value logic (3VL)  in use in SQL. Since Null can translate into "no data present" it shouldn't make sense to accept conversion to any real-world value in any case.

 

Null was not a keyword in AutoIt at the time I was experimenting with 3VL. Storing information in ternary also seemed convenient (and powerful - although it is only proof of concept).

An important consequence of this choice is that Null <> Null and If $n = Null is Null if $n is Null but this is alleviated in SQL with IsNull and IsNotNull.

 

Good information! If I understand you correctly, that's quite a peculiar attribute.

The best would have been to make Default a similar keyword to Null and never accept to convert it to any value in any context.

Again IsDefault and IsNotDefault would then be useful instead of the infamous return value of IsKeyword.

Unfortunately these conventions would break the fundamental paradigm in AutoIt that its variants auto-convert depending on context. On the other side we would no more see things like:

Func _myFunc($arg = $MY_LOVELY_CONSTANT)
    If IsKeyword($arg) = 1 Or $arg = -1 Or $arg = "" Then $arg = $MY_LOVELY_CONSTANT
    ...

 

Clearly a trade-off.

Edited July 29, 2014 by czardas

[Richard Robertson]

If null doesn't equate to null, how could one check for null value?

[czardas]

IsNull according to jchd. My understanding of what jchd said is that it makes sense that an undetermined value should fail when compaired to a second undetermined value, since the values may be determined (as being unequal) by some means later on. Maybe I got that wrong.

Edited July 29, 2014 by czardas

[jchd]

czardas, you got it. If you relax and look twice it makes full sense: a value wich is "not present" is hardly comparable (with <, <=, =, ==, <>, >=, >) to another value which is also "not present".

[Mat]

If null doesn't equate to null, how could one check for null value?

 

If $a <> $a Then ; $a Must be null

And no, I'm not making that up.

[czardas]

So after this fascinating discussion, I'm still none the wiser as to the reason to prefer zero as the value of Default over -1. We appear to have clearly determined that it should be niether True nor False, and I agree with jchd that a numeric interpretation is somewhat arbitrary. Is it because this change can no longer be reversed? Are many default function parameters also going to become zero? I'm not convinced that this is an arbitrary decision.

Edited July 30, 2014 by czardas

[jchd]

Historical (questionable) choice, surely. Jon never really designed the whole baby as he already said. It was an ad-hoc tool which happen to fit bigger and bigger holes over years.

Spiral development of a large piece of code inevitably lead to some inconsistancy. Sometimes you can fix this one at low cost but most of the time you can't either because it would require too large rewrites or it breaks too much legacy code. This is the price of success.

Edited July 30, 2014 by jchd

[czardas]

I accept and understand this. Although not knowing the master plan can make it difficult, and sometimes impossible, to future-proof your code. That's the downside for me.

Edited July 30, 2014 by czardas

[Jon]

So after this fascinating discussion, I'm still none the wiser as to the reason to prefer zero as the value of Default over -1. We appear to have clearly determined that it should be niether True nor False, and I agree with jchd that a numeric interpretation is somewhat arbitrary. Is it because this change can no longer be reversed? Are many default function parameters also going to become zero? I'm not convinced that this is an arbitrary decision.

It was done because people were abusing the fact that Default evaluated to -1.  Passing Default to GUI controls, and created functions that took a numeric parameter and checking for -1 rather than explicitly checking for Default. Or the other way around and checking for Default but the user passing -1.

Any evaluation of a number to try and guess if it is Default is wrong. Apart from triggering a fatal error, the only sensible number we can assign is 0. Not because it is more likely to be significant (it's not, -1 is more abnormal) but because it is more likely to be confused with an actual 0. That makes it more likely that the only sensible use of Default is to indicate one thing, the Default keyword.

The correct use of testing for Default is:

If $something = Default

This will never fail because the user passed a number instead. 

[eukalyptus]

What if Default gives the optional params of a function their optional value?

So the output of _Foo and _Bar is identically:

_Foo(Default, Default, 300)
_Bar(Default, Default, 300)

Func _Foo($sStr = "Blabla", $iX = 0, $iY = 20)
    ConsoleWrite($sStr & " " & $iX & " " & $iY & @CRLF)
EndFunc   ;==>_Foo

Func _Bar($sStr = "Blabla", $iX = 0, $iY = 20)
    If $sStr = Default Then $sStr = "Blabla"
    If $iX = Default Then $iX = 0
    If $iY = Default Then $iY = 20
    ConsoleWrite($sStr & " " & $iX & " " & $iY & @CRLF)
EndFunc   ;==>_Bar

This would save some lines of code (e.g. Array.au3)