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.