AutoHotkey Community

[Guest]

Hi!

I wonder if it would be possible to implement return parameters and local variables for subroutines. I think it should be relativelly easy to do so while maintaining backwards compatibility (and easy to add it to the current AutoHotKey code, too):

1) Return parameters:

- modify Return syntax to Return [, return_value]

- modify Gosub syntax to Gosub, label [, variable_name]

2) Local variables:

- new command: StartLocal. Will mark a start of a new local block

- new command: Local, variable_name. Will declare a variable as local, meaning that it will regain its original value once a current local block ends.

- new command: EndLocal. Will mark an end of a local block

- modify Return. It should end all local blocks started by the current subroutine.

How to add it to AHK:

- StartLocal: a new string array (SA) is allocated on heap, and its pointer is added to a list of local blocks of a current subroutine (GoSub/hotkey block)

- Local, XYZ: Current value of XYZ is stored into SA in a form of XYZ=%XYZ%

- EndLocal: For each string is SA of the active local block, modify the global variable to its stored value. Then remove the SA from a list of SA's and then dispose of it.

- Return: While active local block is linked to a current subroutine, perform EndLocal.

Pepak

[Chris]

Thanks for describing the approach. At the moment, I'm much more interested in return values than I am in local variables. There is a question of whether to simply extend Gosub/Return the way you suggest, or to do something more expansive such as parameters and return values such as this example:

NewString := SomeFunction(%OldString%)

And this also introduces the area of expressions. I was thinking that perhaps the := operator could be used to assign the result of a function call and/or any math or string expression to the left-side variable. This idea needs quite a lot more development since there are many issues, such as how commas would be escaped in the parameter list, how exactly it would work internally, etc.

I'm going to refer to this topic again when the time comes. Feel free to reply or discuss more if you want.

[Guest]

[pepak]

Guess it's time to finally register :-)

[Chris]

[Rajat]

i'd also wanted return values and it'd be nice if available.
_________________

[pepak]

To prevent compatibility issues, the parameters and return code could also be handled by a new command:

Call, Label [, Return_Var [, Param1 [, param2 [...]]]

It would work exactly like Gosub does now, but if there was a return value, it would be stored into variable Return_Var. Param1, Param2 etc. would be passed to the called function as A_Param1, A_Param2 etc.

Return can have a return parameters added safely.

[Chris]

That's a good alternative. Thanks.

[Simpleton]

I was thinking maybe a simpler solution (at least simpler on your end) might be to just do the following:

create a new command called Call like pepak suggested except have it just be:

Call, Label, [Param1, Param2 ... ]

Then have it do a gosub to label and set built in variables to the args:

A_0 = number of args
A_1 = first arg
A_2 = second arg
...
A_%A_0% = A_0'th argument

return values can be handled by output arguments.

Example:

[Chris]

Thanks, that's pretty nice. It has the advantage of allowing a varying quantity of parameters to be passed (though that is probably rarely needed in practice).

The main disadvantage is that it would make scripts less readable and harder to maintain than an approach where the parameters are given local names, such as:

MyLabel, InputColor, OutputX ByRef, OutputY ByRef:
...
return

Something like a "ByRef" keyword is probably needed to support output parameters, where a subroutine can alter the value of a variable passed to it by its caller.

[Simpleton]

ya, that is a problem, though people may have trouble understanding the ByRef thing unless they have other programming experience. And adding references into the language in general makes things a lot more complicated.

Personally I would prefer the perl-like syntax (the one I suggested), which could be implemented quickly and easily, wouldn't make any major changes to the language at large, and at least in my opinion feels more consistant with the rest of AHK. It would also allow people to extend functions without having to worry about it breaking current calls.

The only thing I can think of to help readability and stuff is good use of comments, which isn't much of solution, so those are fairly large problems, but for me at least I think they are outweighed by the benifits.

[Jerry]

Moderator: Jerry had posted something long here which was accidentally deleted.

[Jerry]

Chris,

The previous post

[Chris]

Most likely I pressed Edit instead of the "reply with quoted text". If you don't have the original text of your post, I fear it is lost. Sorry about that.

I've edited the post above to reflect that something is missing, and below is my reply to avoid confusion about who wrote it.