Removal of command syntax

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

Removal of command syntax

29 Apr 2017, 02:58

I have decided to remove commands from v2.

Some background information: Commands vs Functions

I appreciate the arguments from both sides, and I think I better understand the perception that command syntax is easier for beginners. However, I think that in the long run, AutoHotkey is better off with more uniform syntax.

This is basically where I was headed when I started the above topic. I have been dissatisfied with v2, I think, since removing the "can be an expression" rule. I felt that it reduced the convenience of command syntax and deviated too far from Chris Mallett's creation, while simultaneously failing to really solve the underlying problems. Dissatisfaction, reluctance and indecision nearly caused me to abandon AutoHotkey. At this point, I feel much better about dropping command syntax than dropping AutoHotkey or continuing with command syntax.

Before making the decision, I spent considerable time writing more comprehensive (and central) documentation about the syntax, and about fundamental concepts that users are currently expected to learn by example (or already know). The idea was that it might bring me to a closer understanding of the problems with the syntax and how (or whether) to fix them, while also producing better documentation. (At the very least, it had the effect of renewing my motivation to do other things... ;)) It is very much unfinished, so not on GitHub yet. I intend to cover more topics, then review it thoroughly, reorganise it and integrate it with the v1 (and most of it with the v2) documentation. For interest, this is what I have so far (html generated from markdown documents):
My long-term plan is to deprecate the command syntax in v1, improve the documentation to ease beginners into expression syntax, and introduce forward-compatible functions. If you want to help out, consider contributing to AutoHotkey-Future or similar projects, or the documentation.

In retrospect, I think the documentation should have been revised years ago, in particular with regard to var = value and the various forms of IF statements, given that they were acknowledged by Chris as being the two biggest problems with AutoHotkey v1's syntax. But in general, my motivation to work on documentation beyond the minimum of new changes and corrections is pretty low.

I have also been reconsidering percent-sign derefs in quoted strings, as they were primarily an attempt at integrating the "legacy" syntax with expressions and bringing more consistency to the language. Though I'm reluctant to deviate from the v1 expression syntax, I think there are more readable alternatives for variable/expression substitution within strings.
User avatar
Ragnar
Posts: 194
Joined: 30 Sep 2013, 15:25

Re: Removal of command syntax

29 Apr 2017, 04:26

I absolutely agree with your decision and will help to revise the documentation.
Helgef
Posts: 3163
Joined: 17 Jul 2016, 01:02
Contact:

Re: Removal of command syntax

29 Apr 2017, 04:55

lexikos wrote:I have decided to remove commands from v2.
Some background information: Commands vs Functions
I appreciate the arguments from both sides, and I think I better understand the perception that command syntax is easier for beginners. However, I think that in the long run, AutoHotkey is better off with more uniform syntax.

Whatever the arguments are, you making a decision is the only way for the project to move forward, and I'm sure the community (present and future) supports the decision and appreciate the fact that the discussion has come to an end. I look forward to moving to v2 when the big changes are done.

Cheers.
guest3456
Posts: 2400
Joined: 09 Oct 2013, 10:31

Re: Removal of command syntax

29 Apr 2017, 07:20

1. +1 on everything. I guess AutoIT eventually came to the same conclusion. Whether people like the decision or not, your renewed interest can only be a Good Thing.

2. If people still like the command syntax, they can continue to use AHK v1. That doesn't have to die out. I don't think you should deprecate the Commands in v1. It sounds like you're trying to transition v1 into v2 but if that's right, I don't really like that idea. I think they should stand on their own.AHK v1's "identity" can remain with it. The v2 docs can explain the transition. I'm not sure how I feel about the function wrappers yet but I don't think they can hurt

3. Those docs are excellent, and will only get better with iterations and contributions. Great work. That's what I had in mind.

4. Because of this change, should discussion be revisited about moving to a new file extension? I guess .py and .php never change when they bump versions, so maybe not

5. I loved the php-like convenience of %derefs% inside quoted strings. I'm curious about what alternatives you are considering.. On second thought, I guess this change will pretty much eliminate %derefs% syntax. Would those still exist anywhere? In which case, I guess then I'd have to be in support of consistency

just me
Posts: 5459
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Removal of command syntax

29 Apr 2017, 09:50

I highly appreciate your decision. I cannot help with the textual parts of the docs, but I can offer to work on the code examples. Let me know when, where, and how to do it.

lexikos wrote:My long-term plan is to deprecate the command syntax in v1, improve the documentation to ease beginners into expression syntax, and introduce forward-compatible functions.
Does this really mean you want to revise the AHK 1.1 documentation? IMHO, it would be wasted effort. Besides inevitable buf fixes you should restrict your activities to v2. I think it's more than enough work for one developer.

guest3456 wrote:I'm curious about what alternatives you are considering ...(for derefs in quoted strings)
Me too!
lexikos
Posts: 6130
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Removal of command syntax

29 Apr 2017, 19:18

guest3456 wrote:Because of this change, should discussion be revisited about moving to a new file extension?
I don't see any connection between this and that. If you and others wish to discuss it, please start a new topic. The main thing stopping me from using a new file extension is that there are none that feel right.

just me wrote:Does this really mean you want to revise the AHK 1.1 documentation?
No, want is the wrong word when it comes to revising documentation.

Teaching beginners to write code using expressions will be the same regardless of which version it is written for, except for a few notes warning about exceptions to the syntax (which also serve to promote v2).
Besides inevitable [bug] fixes you should restrict your activities to v2.
It was my intention to drop all work on v1 several years ago, but lack of progress with v2 (and occasional unrelated ideas) changed that. Anyway, my interests range outside of what's strictly relevant to the v2 project. Restricting what I work on based on any criteria other than what takes my interest generally only serves to kill my motivation. Ultimately, whether or how much I develop my ideas for v1 will hinge on how much it takes my interest, not how much I try to dedicate my time to one or the other.
Let me know when, where, and how to do it.
If you see something that you think needs fixing/improving, try fixing/improving it.
User avatar
jeeswg
Posts: 4983
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Removal of command syntax

29 Apr 2017, 20:16

AutoHotkey's functions are exactly the same as those used with Excel cells and Excel VBA. They were very easy for me to learn. In my view removing the command syntax won't hurt beginners one bit.

Problems with AutoHotkey for me generally came from confusion regarding % signs and double quotes, with 'if', assignments and parameters, the remedy for this is one good link on strings.

I never cut corners, but I think that if you left the current documentation 99.9% unchanged that would be fine. What I think is needed is one or two good beginner tutorials. If a few people have a go at this, we can learn from each other's attempts and improve our own, and it will speed up the creation of an official tutorial, which can draw from this material. I am writing beginner tutorials on AHK v1/v2/v1 and v2 together, strings, mathematics, conversion.

I feel that within a few weeks, my GUI via DllCall, conversion/indentation/cleaning scripts and tutorial projects will all be finished. Many are near completion now.

I am interested about what alternatives you have to percent-sign derefs in quoted strings, the idea does make me quite nervous, although generally I am interested in new ideas. This was the one feature of the legacy syntax I liked: for WYSIWYG continuation sections, filenames, and SendInput. Although I would be happy for AutoHotkey not to automatically dereference % signs in text, and to use a built-in or custom Deref function (every odd item is text, every even item is a variable).

Many thanks Lexikos, for many things.
SirRFI
Posts: 404
Joined: 25 Nov 2015, 16:52

Re: Removal of command syntax

30 Apr 2017, 08:10

In my scripts I avoided commands as much I could, because I often use expressions or do things "dynamically". It's a good decision, especially given fact how coexistence of both commands and functions at the same time could be confusing to newcomers/learners.
Use [code=autohotkey] forum tag to share your code.
Click on (Accept this answer) on top-right part of the post if it has answered your question / solved your problem.
User avatar
fincs
Posts: 500
Joined: 30 Sep 2013, 14:17
GitHub: fincs
Location: Seville, Spain
Contact:

Re: Removal of command syntax

30 Apr 2017, 17:05

At first, I was somewhat shocked that such a bold decision had been made. However, after thinking more reasonably about it and reading carefully the discussion that has been made about the subject, I have arrived at the same conclusion: command syntax has no relevance or usefulness anymore. It is the direct culprit of the problems that many novices face when learning to use AutoHotkey. It introduces unnecessary dimorphism, confusion and prejudice against the AutoHotkey language. Therefore I applaud this decision.
fincs
Windows 10 x64 Build 17134 / AutoHotkey v1.1.29.01
Get SciTE4AutoHotkey v3.0.06.01 - [My project list]
HotKeyIt
Posts: 1689
Joined: 29 Sep 2013, 18:35
Contact:

Re: Removal of command syntax

30 Apr 2017, 17:35

fincs wrote:At first, I was somewhat shocked that such a bold decision had been made. However, after thinking more reasonably about it and reading carefully the discussion that has been made about the subject, I have arrived at the same conclusion: command syntax has no relevance or usefulness anymore. It is the direct culprit of the problems that many novices face when learning to use AutoHotkey. It introduces unnecessary dimorphism, confusion and prejudice against the AutoHotkey language. Therefore I applaud this decision.

+1
User avatar
hoppfrosch
Posts: 321
Joined: 07 Oct 2013, 04:05
GitHub: hoppfrosch
Location: Rhine-Maine-Area, Hesse, Germany
Contact:

Re: Removal of command syntax

01 May 2017, 23:52

I always considered the parallel existance of command and function syntax more a source of problems than an ease for beginners. Therefore I only can fully support your decisions.

And even if I wouldn't agree with all details, the most important is that any decisions are made and AutoHotkey development hopefully gathers pace again.

+1
SirRFI
Posts: 404
Joined: 25 Nov 2015, 16:52

Re: Removal of command syntax

02 May 2017, 19:06

To my understanding everything will be a function now, even MsgBox will be like MsgBox("Text","Title"), so it won't be needed to force expression any more? Briefly reviewing the 3 pages of documentation got me little confused, especially they seemed to be written before commands removal decision, and mixed up with "legacy syntax". In speak of legacy syntax - I suggest to keep it on exclusive doc page for those, who had used v1 and moved to v2.



Additionally got following possibly off-topic questions:
• What happens to pseudo-arrays in v2? Wouldn't it be better to have functions return actual arrays or objects instead of "MyVariable", "MyVariable0", "MyVariable1", "MyVariable2"? This should allow easier managing and further work with the results.
• With literal assignment removed, does it mean = is used only for case-insensitive comparison?
Use [code=autohotkey] forum tag to share your code.
Click on (Accept this answer) on top-right part of the post if it has answered your question / solved your problem.
lexikos
Posts: 6130
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Removal of command syntax

02 May 2017, 22:12

SirRFI, it hasn't even been a week since I announced that the change **will be** made. I have neither made the change nor, obviously, updated the entire (or any part of the) documentation to reflect it.

Your first off-topic question implies that you have not read v2-changes or the documentation for the v2 functions/commands in question, nor used them in v2-alpha.

As for =, yes, it is only for case insensitive equality. However, in v1 there are several other ways it is used. At the moment these are described under "different equals" in the "language" document in my first post.
SirRFI
Posts: 404
Joined: 25 Nov 2015, 16:52

Re: Removal of command syntax

03 May 2017, 08:02

lexikos wrote:SirRFI, it hasn't even been a week since I announced that the change **will be** made. I have neither made the change nor, obviously, updated the entire (or any part of the) documentation to reflect it.

I know, I just wanted to make sure on the syntax and share my opinion on including legacy syntax in the documentation while on it.



lexikos wrote:Your first off-topic question implies that you have not read v2-changes or the documentation for the v2 functions/commands in question, nor used them in v2-alpha.

I actually did read a bit (not all) of the changes and thoughts before posting. I know some commands/functions like WinGetControls returns an array in v2, but I wonder if it is/will be done to everything - I haven't seen this stated, but I could have missed it. I'll take it as yes. And yes, I didn't use v2 yet.
Use [code=autohotkey] forum tag to share your code.
Click on (Accept this answer) on top-right part of the post if it has answered your question / solved your problem.
User avatar
jeeswg
Posts: 4983
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Removal of command syntax

18 May 2017, 09:12

If functions are due to be removed, what about return/break/continue/Loop, they will still be 'commands' right?

[EDIT:]
From AHKB: Break,Continue,Else,Gosub,Goto,If,Loop,Return,While
From AHKL: Catch,Finally,For,Throw,Try,Until
(Although I did see some talk about function syntax for Loop.)

Btw I had already converted many of my scripts to function syntax, and the one and only disadvantage is having lots of commas, brackets and double quotes everywhere, which can be confusing to read/maintain.

I had thought before that a Verbatim 'command', essentially a one-line continuation section might be very useful.

Note: the Options parameter would have syntax like a function parameter (and would be based on the continuation section 'parameter'. Also perhaps 'AutoDeref' could be optionally turned on/off. This would be especially useful for clarity with things like:
"%vPathExe%" "%vPath%" "%vParam1%" "%vParam2%"

Code: [Select all] [Download] GeSHi © Codebox Plus

Verbatim, Options, MyText

[EDIT:] I've presented it using command syntax, because that's the first syntax I thought of that didn't look like a function. I.e. there may be a case for a handful of 'functions' that don't use function syntax.
lexikos
Posts: 6130
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Removal of command syntax

20 May 2017, 21:19

My initial plan was to "simply" disable command syntax (and percent derefs) and require full function syntax (including parentheses) for all functions, keeping the v2 syntax close to a subset of the v1 syntax. However, parentheses don't seem suitable for control flow statements (especially Loop), and are a minor inconvenience that doesn't seem to have much value. So I'm considering allowing the parentheses to be omitted, or to put it another way, keeping commands but making all parameters expressions and removing the initial output var.

On the other hand, smart editors and hotstrings can mostly eliminate the inconvenience of the extra characters. For example, when auto-completing a function name, the parentheses can be inserted automatically (and the caret placed between them).

Removing the initial output var (previously used for the function return value) limits the difference between "command" and "function" mode to just whether you use parentheses, which makes it easier to remember/learn the syntax or read scripts written by others. (It has been suggested before, but at the time I thought it seemed incongruous to limit the legacy command syntax to just situations where you don't require a return value.)

For Loop, I think it's adequate to just enable expressions (and OTB) by default.

For Goto/Gosub/Break/Continue, I think it's best to accept a literal label by default. Break and Continue don't support variables. Goto label%n% would be translated to Goto("label" n) (this is not valid yet, because I overlooked goto/gosub when I changed Loop/Until/Return to support parentheses).

All of the other control flow statements (I think of them as such, not as "commands") already accept expressions/variables and do not need to change.

I considered whether directives like #Include and #IfWinActive should emulate expression syntax, but I'm leaning toward leaving them as they are.
User avatar
jeeswg
Posts: 4983
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Removal of command syntax

20 May 2017, 22:18

Thanks for this response Lexikos.

When considering updating my list of commands/functions/directives/variables to reflect the changes, I realised that perhaps I should separate control flow statements. It then made me realise that there would still be command-like things in AHK unless one was deliberately radical about 'removing commands'. I personally don't mind some/a lot of command-like remnants.

One wonders if adding parentheses, does make something look odd, or if it's just habit.

It sounds like commands will still exist, but function-like commands with function-like parameters.

Because of hotstrings etc, I don't mind using extra characters, so my main concern is readability, mainly for the Run command. Verbatim, would allow you to move a complicated parameter to a separate line and avoid having obfuscating quotes/commas/parentheses/backticks around/inside it. Also you could copy and paste command-line parameters, from/to the script, as they are, which I think is a subtle but important advantage.

AHK Basic's solution to be helpful, was to always look out for environment variables. I think a better approach would be something like this:

Code: [Select all] [Download] GeSHi © Codebox Plus

Verbatim, ev, MyDir, C:\Users\%username%\AppData\Local\Microsoft\Windows\Themes
User avatar
Exaskryz
Posts: 2873
Joined: 17 Oct 2015, 20:28

Re: Removal of command syntax

21 May 2017, 17:43

lexikos wrote:My initial plan was to "simply" disable command syntax (and percent derefs) and require full function syntax (including parentheses) for all functions, keeping the v2 syntax close to a subset of the v1 syntax. However, parentheses don't seem suitable for control flow statements (especially Loop), and are a minor inconvenience that doesn't seem to have much value.


I will put forth the disclaimer I haven't used AHK v2 yet. But I did want to bring up some concerns. So you're distinguishing between control-flow and action functions basically?

Here's an idea I have regarding at least the Loop command. countVar:=Loop(Terminal Condition) - countVar basically serves as an A_Index value you can use outside the loop (or within inner loops), and it contains the number of times the Loop has been started, just like A_Index. Loop(2) means run twice, Loop(x>5) means stop when x is greater than 5, Loop(GetKeyState("Space","P") means look while Space is pressed -- basically just merged the While and Loop together. I'm not sure an Until command is necessary, I haven't found a use case that can't just be used in a While expression. Then you might make the Loop derivatives their own functions like Parse() and Read()?

lexikos wrote:So I'm considering allowing the parentheses to be omitted, or to put it another way, keeping commands but making all parameters expressions and removing the initial output var.


Alternatively, are we thinking something like FileReadLine could be converted to output:=FileReadLine, "MyFile.Txt", 5? This would be differentiated from wanting a totally literal string of that value as output:="FileReadLine, ""MyFile.Txt"", 5" and would potentially mean reserving the FileReadLine as a term that can't be used as a variable, assuming we still have the ability to use outputvar:=copy_this_value and such.

lexikos wrote:On the other hand, smart editors and hotstrings can mostly eliminate the inconvenience of the extra characters. For example, when auto-completing a function name, the parentheses can be inserted automatically (and the caret placed between them).


While true, it does put a barrier to beginners, which as was covered in the previous topic command syntax at least helps get their foot in the door even if they'll stumble later. If there were any way to make parentheses optional, I'd be in favor of it.



Removing the initial output var (previously used for the function return value) limits the difference between "command" and "function" mode to just whether you use parentheses, which makes it easier to remember/learn the syntax or read scripts written by others. (It has been suggested before, but at the time I thought it seemed incongruous to limit the legacy command syntax to just situations where you don't require a return value.)


I would be alright with that kind of distinction, like using output:=FileReadLine("MyFile.txt",5) vs Loop 2 and GoSub "label"

Lexikos wrote:For Loop, I think it's adequate to just enable expressions (and OTB) by default.

For Goto/Gosub/Break/Continue, I think it's best to accept a literal label by default. Break and Continue don't support variables. Goto label%n% would be translated to Goto("label" n) (this is not valid yet, because I overlooked goto/gosub when I changed Loop/Until/Return to support parentheses).

All of the other control flow statements (I think of them as such, not as "commands") already accept expressions/variables and do not need to change.


If there aren't many other control-flow commands/functions, could we get them all converted to functions if we can just think of output values that could have a purpose? One idea for a GoSub value would be the time lapsed from when it went to the subroutine to when it was returned. A possible GoTo value would be the name of the label (hotkey, timer, etc.) that started the thread.

Lexikos wrote:I considered whether directives like #Include and #IfWinActive should emulate expression syntax, but I'm leaning toward leaving them as they are.


If all #'s are synchronous in what syntax they use, that would be best IMO. If that means using a syntax expression that requires literal strings because we won't have #If use #If this=%var% and instead default it to #If this=var (equivalent to v1 #If (this=var)), then the explicitly defined literal strings it should be.
lexikos
Posts: 6130
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Removal of command syntax

21 May 2017, 19:10

Exaskryz wrote:... basically just merged the While and Loop together.
Just use While !(terminal condition).

I'm not sure an Until command is necessary, I haven't found a use case that can't just be used in a While expression.
Of course it isn't necessary. Neither is While - you can just use If and Break. While can be used only if the expression is to be evaluated before each iteration (and in particular, before the first iteration).
Then you might make the Loop derivatives their own functions like Parse() and Read()?
It wouldn't work that way (with an inverted While like you've described). The loop sub-commands need to remember state (current position in string, current position in file, find-file handle, etc.) between calls, and separate for each Loop. The For-loop is designed to handle that via an enumerator object, which would mean calling the function once (to create the enumerator) and then implicitly calling Next on the enumerator. Loop sub-commands are all handled internally, using recursion, not iteration (i.e. the loop sub-command itself executes or "calls" the loop body as needed). However, the current alpha build supports a function-like syntax: LoopParse( ... ). Loop Parse() would be ambiguous because Loop expression = Loop Count.

Alternatively, are we thinking something like FileReadLine could be converted to output:=FileReadLine, "MyFile.Txt", 5?
No. Parentheses would be required if you want the return value.

While true, it does put a barrier to beginners, which as was covered in the previous topic command syntax at least helps get their foot in the door even if they'll stumble later.
I don't buy it. No one is going to spontaneously start writing valid code. They will read the documentation and/or learn from examples or other scripts, which will use whatever syntax is available. Either way each user will need to learn concepts they may not be familiar with, such as to always enclose literal text in quote marks. Requiring parentheses around the parameter list is a very simple rule, and easier to remember if there are no exceptions. (That's not to say I was necessarily planning to make them mandatory.)

GoSub "label"
I think that would be incongruous, like goto/gosub aren't a real part of the language, since labels are defined without quote marks. (On the other hand, I hadn't considered the other functions like Hotkey(), which will require quote marks.)
One idea for a GoSub value would be the time lapsed from when it went to the subroutine to when it was returned.
That's silly. If Gosub() has a return value, it should be the return value of the subroutine (i.e. allow return with a parameter).
A possible GoTo value would be the name of the label (hotkey, timer, etc.) that started the thread.
Goto can't have a return value. Execution jumps away and does not return.
User avatar
Exaskryz
Posts: 2873
Joined: 17 Oct 2015, 20:28

Re: Removal of command syntax

21 May 2017, 20:27

All great info, I just want to clarify some points that I wasn't clear on. (Not in any way to persuade anyone, just spitballing here.) I wasn't thinking about using a Loop Parse(), but instead a Parse() alone. My thinking on a GoSub() not returning the return value from it's target label is.. why not call a custom function instead, and grab your own return value? And yeah, the use of a time lapse is pretty silly, but it was one example of a possibility. And on my idea of a GoTo, I wasn't thinking of it having a return, but before it jumps away it just records whatever started it. i.e. instead of in v1 using starter:=A_ThisHotkey then GoTo label[/b], you could get the value of A_ThisHotkey logged into the variable starter with [c]starter:=GoTo("label"). 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.

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 8 guests