Problem with built-in function 'func' Topic is solved

[Helgef]

Func() was opitimised in v2.0-a090-ae96c4a, maybe it caused the following unexpected result

Code: Select all

; v2.0-a090-ae96c4a
msgbox isobject(func(true ? "abs" : ""))			; 0 this is unexpected
; The following is expected
msgbox isobject(func(false ? "" : "abs"))			; 1
a := true ? "abs" : ""	
msgbox isobject(func(a))							; 1
msgbox isobject(func(true && "abs"))				; 1

defining a function f, and replacing abs with f does not change the behaviour.

Cheers.

(simple benchmarking shows positive results for the optimisation )

[lexikos]

I kept forgetting this. The fix will be in the next update.
[Edit: Fixed in v2.0-a094.]

Func("" && "ceil") and Func("floor" || "ceil") would both also fail. I believe this only occurs with short-circuit operators (?:, && and ||).

This also affects OutputVar detection and DllCall optimization.

Code: Select all

MouseGetPos(true ? x : 0)  ; Raises a load-time error in v2.0-a093
MouseGetPos(true ? x : y)  ; Works okay and sets x

Btw, true ? Func("abs") : Func("") should be faster than Func(true ? "abs" : ""). The latter will not be optimized.

[Helgef]

The fix will be in the next update.

Thanks.

Btw...

Good point, thanks.

Cheers.

[just me]

Func(true ? "abs" : "")Looks interesting. What does Func("") return (assuming that it is a valid call of Func())?

[Helgef]

I guess it returns an empty string. Func("nonexistentfunc") might as well throw an exception, since eventually trying to use the return value will cause an exception, it is better to be notified where the error first occured. Isfunc or try should be used to avoid/handle it if ecessary.

Cheers.

[lexikos]

Func("") returns an empty string, as documented.

eventually trying to use the return value will cause an exception

Trying to invoke the return value (an empty string) will cause an exception. There is another way to use the return value which will not:

Code: Select all

if f := Func(name)

I was initially going to remove IsFunc because this is more efficient than if IsFunc(name) .. f := Func(name). Now, if Func(name) may create a closure which is immediately destroyed, whereas if IsFunc(name) does not. Still, it is probably rare that one would call IsFunc(fn) and not follow it with:

• Func(fn) to retrieve the reference;
• %fn%() to call the function by name; or
• an assignment to store the function name to be called later (either with a dynamic function call or as a method).

In all of those cases, it is better to first retrieve the reference with f := Func(fn), validate it, and then use/store the reference. On the other hand, in some cases it is more convenient for Func(fn) to throw: when fn is expected to be valid, especially if the current function can't continue without a valid Func.

One problem with exceptions is that handling one requires multiple statements - i.e. there aren't any syntax shortcuts, probably because they're supposed to be used only in "exceptional" circumstances. That doesn't necessarily have to be the case for AutoHotkey.

It might be helpful to have a "non-dynamic" operator or other syntax for a function reference, which can be validated at load-time (and could be more succinct). I think fincs suggested @myfunc, but I couldn't find the post (and I didn't like the look of it at the time).

[Helgef]

Thank you for your answer lexikos, that makes sense.

This also affects OutputVar detection

I have observed some problems, which I think is related to this. There are problems with load- and run-time validation of outputvars, examples,

Code: Select all

; No error, neither at load- nor run-time.
caretGetPos x, "y"	
strreplace "a","a","b", "out"

Compare to,

Code: Select all

; load-time errors:
caretGetPos , "y" 	
caretGetPos "y"
strreplace "a","a",, "out"

There should at least be a run-time error, as currently is the case with the commands (eg, mouseGetPos as you showed) which haven't yet been converted to BIFs.

Cheers.

[lexikos]

Fixed in v2.0-a097.