Removal of command syntax

Discuss the future of the AutoHotkey language
lexikos
Posts: 6668
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Removal of command syntax

21 May 2017, 23:07

Exaskryz wrote:But I wouldn't mind if GoTo (and GoSub) just don't have any return values if we do not need to worry about creating complete uniformity.
It is not necessary to give gosub() a return value just because it looks like a function. There are plenty of functions with no return value.
why not call a custom function instead, and grab your own return value?
For the same reasons that you would use a sub in the first place. If you don't have any reasons, forget gosub and use functions.
you could get the value of A_ThisHotkey logged into the variable starter with starter:=GoTo("label")
Impossible, unless you want to overload the syntax so that this really isn't a function call and assignment, but special "goto" syntax. (Or use a ByRef parameter.) As I said, when Goto executes, execution transfers to the target label and does not return. The assignment would never execute.

Anyway, this is what functions with parameters are for. Do not use goto like this.

Actually, your suggestion doesn't make any sense. How does the program know to put A_ThisHotkey into starter, from starter:=Goto("label")? You could just use starter:=A_ThisHotkey, Goto("label") if Goto was allowed inside an expression (it probably won't be).
HotKeyIt
Posts: 1894
Joined: 29 Sep 2013, 18:35
Contact:

Re: Removal of command syntax

22 May 2017, 16:16

How about to save return value in A_Result for command style function?

Code: Select all

FileRead "C:\Temp\Text.txt"
MsgBox A_Result
User avatar
nnnik
Posts: 4326
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Removal of command syntax

23 May 2017, 04:25

What about code blocks {} or (param*){} rather return a function object with the specified code and parameters - than having them executed right away.
You also said something about allowing access towards global local and static space via object access ( only global.varname for now but I think you are going to ask yourself why you shouldn't allow other object access in time )
Wouldn't it be possible to let an if function set the local space object of such a function object towards that of the outer local object and allow:

Code: Select all

if( condition, { code, can, be, here })
Functions could also be defined like this:

Code: Select all

function := (params){code}
This would also allow us to increase the modularity of the language by allowing each script to have it's own unique global space object.
Recommends AHK Studio
lexikos
Posts: 6668
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Removal of command syntax

26 May 2017, 23:13

HotKeyIt: It's been brought up before, and I still don't like it.

I think the first instance of this suggestion was by Frankie in Oct 2011. My response was first "I don't think an implicit output variable for the return is a good idea. I certainly wouldn't want to use A_LastReturn any more than ErrorLevel." then after more thought, "It does not seem like a natural part of the language. Though it is hardly different from using ErrorLevel to return a value, it lacks the familiarity of ErrorLevel. The variable names are awkward and barely meaningful."

Some other users suggested other names or agreed with previous suggestions, but didn't add much of relevance.

There are several drawbacks to A_Result (or any other name) and very little benefit:
  • It is hardly more convenient than := ( ).
  • The name would nearly always be less meaningful than what an author might use if assigning to a variable explicitly.
  • A_Result would be changed implicitly by any command, which makes the code both less clear (than code making an explicit assignment) and more error-prone.
  • If one discovers that one needs to call another command in between A_Result being set and it being used, one has to add an assignment and convert the code from using A_Result to using some other variable. Better to just use a function call in the first place.
nnnik: You seem to be unwittingly talking about function closures and anonymous functions, which are present in several languages, including JavaScript, Lua and C#. They are things I am interested in implementing, but do not intend to include in v2.0. The sequence ) { is already treated as an error and can therefore safely be used for this purpose in any future release.
User avatar
nnnik
Posts: 4326
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Removal of command syntax

27 May 2017, 00:12

Well thats the right track but what about the rest of the suggestions I mentioned?
Recommends AHK Studio
lexikos
Posts: 6668
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Removal of command syntax

27 May 2017, 01:53

What are you talking about?
User avatar
nnnik
Posts: 4326
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Removal of command syntax

27 May 2017, 02:18

The thing about allowing changes in spaces of code.
Recommends AHK Studio
HotKeyIt
Posts: 1894
Joined: 29 Sep 2013, 18:35
Contact:

Re: Removal of command syntax

27 May 2017, 03:59

lexikos wrote:HotKeyIt: It's been brought up before, and I still don't like it.

There are several drawbacks to A_Result (or any other name) and very little benefit:
  • It is hardly more convenient than := ( ).
  • The name would nearly always be less meaningful than what an author might use if assigning to a variable explicitly.
  • A_Result would be changed implicitly by any command, which makes the code both less clear (than code making an explicit assignment) and more error-prone.
  • If one discovers that one needs to call another command in between A_Result being set and it being used, one has to add an assignment and convert the code from using A_Result to using some other variable. Better to just use a function call in the first place.
I see, that makes sense, I just have to get used to that :)
lexikos
Posts: 6668
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Removal of command syntax

27 May 2017, 05:51

nnnik: Your "if function" made absolutely no sense to me, so I could be mistaken, but I'm fairly certain that your suggestion would be totally redundant if the things that I mentioned were implemented. I suggest that you read up on them, and then explain how your suggestion is different.

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 12 guests