Command syntax - "This parameter can be an expression"

[lexikos]

In v1, generally any command parameter which accepts only numbers has a phrase in the documentation like "This parameter can be an expression," meaning that one can write an expression without having to use the % prefix.

v2.0-a026 tentatively changed the behaviour so that % is always required, ostensibly because the syntax varying between parameters is a source of confusion.

However, I've come to see that this directly opposes (to quote Chris) a "key philosophy behind AutoHotkey" -- convenience -- and seems to contradict the decision to keep command syntax, since having the two disparate syntaxes is still a potential source of confusion. I also feel that maybe it's taking things too far, turning AutoHotkey into something else.

As for ease of use for beginners, I think it is of questionable benefit.

• When reading a script, it's fairly obvious that something like x+y is an expression.
• When writing a script, one can write % x+y if in doubt and it will work.
• One always needs to know what the parameter is for and what kind of value it accepts, so the argument that it's hard to remember whether a particular parameter accepts an expression doesn't really hold. As far as I'm aware, the only parameters which accept numbers but not expressions are those which also accept non-numeric values, such as "Off". In most such cases, it will be immediately obvious on attempting to run the script that an expression is not accepted; for example:

  Code: Select all

  SetTimer foo, x*1000  ; Causes a load-time error in v1 and v2

So, I intend to reverse the change and allow expressions in numeric parameters, but I invite comments in case there is an argument or point of view that I haven't considered.

[fincs]

My opinion is that the change should not be reversed because it would make command syntax highly unpredictable and unintuitive. Treating certain parameters of certain built-in functions as "also expressions" would result in second-class treatment of script-defined functions as well as blatant inconsistencies in syntax. There's also the issue of v2 syntax highlighting either becoming severely crippled or needing to use a more complex algorithm in order to figure out how to highlight arguments in command syntax. Personally I don't use "also expression" arguments at all, not even in v1.x.

[lexikos]

I was hoping for more reasonable and practical comments.

It is very easily predictable. If the arg accepts a number and only a number, it accepts an expression. Perhaps it is a shortcoming of the documentation that this is never explained. Would you say that it is intuitive for x+y to be taken literally even though the only valid values for the parameter are numbers?

Script functions would have just the same capabilities as they do now, or more if there was a way to define the syntax of the function.

Inaccurate syntax highlighting has never been a big problem for v1; why would it be for v2? Even so, the tools can be fixed.

Did you consider either of the focal points of my previous post?

• Ease of use for beginners (whether there is any actual impact)
• Convenience

Personally I don't use "also expression" arguments at all, not even in v1.x.

Really? At all? Not even in SciTEDebug.ahk?

That brings me to another point: re-training users and the potential for errors. It's very likely that users coming from v1 will make the mistake of omitting % with commands like SendMessage. I know I've done it multiple times. Currently that doesn't cause any error - non-numeric values like SomeVarName are generally "coerced" to 0.

[fincs]

It is very easily predictable.

Not without knowing beforehand which built-in functions accept which numeric parameters.

Would you say that it is intuitive for x+y to be taken literally even though the only valid values for the parameter are numbers?

In command syntax, yes. I expect non-OutputVar arguments to be always interpreted as unquoted text. If I wanted to use x+y I'd clearly and unambiguously write an expression using %. Notice the unintuitive change in behaviour when a user replaces Sleep x+y with MsgBox x+y.

Script functions would have just the same capabilities as they do now, or more if there was a way to define the syntax of the function.

Exactly, thus they are second-class citizens for not being allowed to have special always-expression parameters in command syntax. I believe it is bad language design to give built-in functions special treatment compared to user-defined functions. Several languages which used to have this kind of special behaviour have moved towards eliminating it (e.g. Python and Lua). Note that flow of control statements don't count as functions.

Really? At all? Not even in SciTEDebug.ahk?

Maybe in old code I wrote years ago, but most surely not in newer code.

Inaccurate syntax highlighting has never been a big problem for v1; why would it be for v2? Even so, the tools can be fixed.

Yes, and while it is not excessively important it has always been extremely ugly and totally unlike syntax highlighting for other languages; giving it a feel of unprofessionality and fueling the perception of AutoHotkey not being a proper programming language. I do not wish syntax highlighting to be woefully inaccurate in v2, as it has been for v1.1 due to language design.

That brings me to another point: re-training users and the potential for errors.

v2 already forces users to take re-training in many areas; especially obscure areas due to subtle changes in behaviour.

[lexikos]

Not without knowing beforehand which built-in functions accept which numeric parameters.

And? How will you use the function or interpret the meaning of the values being passed to it if you don't know what the parameters are?

Exactly, thus they are second-class citizens for not being allowed to have special always-expression parameters in command syntax.

The second half of the sentence you quoted is intended to point out that your argument is irrelevant if user-defined commands can be defined to accept expressions. Aside from that, I'm happy with user-defined functions being so-called "second-class citizens".

v2 already forces users to take re-training in many areas;

So the more re-training, the better? No.

Yes, and while it is not excessively important it has always been extremely ugly and totally unlike syntax highlighting for other languages; giving it a feel of unprofessionality and fueling the perception of AutoHotkey not being a proper programming language.

So make a better highlighter.

I think it's clear that we disagree. Does anyone else have any comments?

[toralf]

Yes, but just a small reflection of my own practice:
In v1 I always put a % in front of a command parameter if I want an expression. One reason is clarity that the following is meant to be an expression. And I think it would be consistent with parameters that expect non numeric parameters.
Thus regardless if the parameter is numeric or not it is either
Text
%var%
% expression

[toralf]

BTW are there any parameter that do not accept expression?

[guest3456]

Yes, but just a small reflection of my own practice:
In v1 I always put a % in front of a command parameter if I want an expression. One reason is clarity that the following is meant to be an expression. And I think it would be consistent with parameters that expect non numeric parameters.
Thus regardless if the parameter is numeric or not it is either
Text
%var%
% expression

yes that is fine and well and your particular preference.

however the discussion is whether or not the small subset of command arguments that can accept expressions WITHOUT using the % (to force expression mode) should remain or not

as for me

it took me a while to grasp command syntax at all, and it was mainly the confusion between expressions and literal text. once i understood that all command parameters were literal strings unless forced into an expression with the % prefix, then it made sense.

i think AHK's attempt to cater towards beginners with its command syntax and literal text is not a bad thing. my guess is that Chris originally had these types of scripts in mind:

Code: Select all

Run, notepad.exe
WinActivate, Untitled - Notepad

^RButton:
   Send, Sincerely{enter}John Doe
return

however very soon (really as soon as anyone starts to use variables) beginners are forced to learn the difference between a literal string and an expression. i wonder if it wouldn't be better to just force them to learn that right from the start instead of having to juggle between the two. i dont know the answer to that

alas, with AHK i came to pretty much consult the docs ALWAYS. looking up commands and their arguments and possible values, etc. and i would guess thats the same for most people.

as for the argument about "unprofessional/inconsistent" syntax, i think its valid, but as i've said in the past, i think it could also be easily handled with a better tutorial/webpage explaining the language syntax. copywriting is a huge industry and theres a reason for that

so maybe i've just become used to AHK's quirks, but i dont have any particular problems with reversing the change to re-allow expressions for some command parameters.

[toralf]

Sorry, I might not have been clear. My preferred solution would be that AHK always requires a % for expressions in command parameter for the reasons mentioned above.
But again: It would just be fitting well to the style I already write my code currently.

[HotKeyIt]

I also think expression should always require %, just for consistency with all commands/functions.
But commands like SendMessage that require a number should trow an error if they get a literal string or expression without %.

[fincs]

So the more re-training, the better? No.

My sentence was supposed to argue that there is already the need for quite a lot of retraining, and changing this behaviour would not make any significant difference.

So make a better highlighter.

I already did.

I also think expression should always require %, just for consistency with all commands/functions.
But commands like SendMessage that require a number should trow an error if they get a literal string or expression without %.

This seems like a good way to mitigate effects of transitioning from v1.1 to v2 concerning expressions in command syntax, especially at load-time.

[just me]

... since having the two disparate syntaxes is still a potential source of confusion.

Yes, but it will be even more confusing if you have to force an expression for strings but not for numerical values. That's why I think v2 should not be changed.

[OT]IMO, convenience is the main source of bugs![/OT]

[jethrow]

however the discussion is whether or not the small subset of command arguments that can accept expressions WITHOUT using the % (to force expression mode) should remain or not

Do we have a list of these? Visual examples of where it wouldn't be desirable to require a % for expressions could help clarify the discussion.

Personally, this has never been an issue for me, though I always default to using a % to force expressions in commands.

[lexikos]

This is the currently unused list of parameters (by command and parameter index) which are marked as numeric, parsed from g_act in globaldata.cpp:

Code: Select all

ClipWait 1, 2
ControlClick 5
ControlMove 2, 3, 4, 5
DirCopy 3
DirDelete 2
DirSelect 3
FileCopy 3
FileCreateShortcut 8, 9
FileInstall 3
FileMove 3
FileSetTime 1
ImageSearch 3, 4, 5, 6
MouseClick 2, 3, 4, 5
MouseClickDrag 2, 3, 4, 5, 6
MouseGetPos 5
MouseMove 1, 2, 3
PixelGetColor 2, 3
PixelSearch 3, 4, 5, 6, 7, 8
PostMessage 1, 2, 3
Random 2, 3
SendLevel 1
SendMessage 1, 2, 3, 9
SetControlDelay 1
SetDefaultMouseSpeed 1
SetKeyDelay 1, 2
SetMouseDelay 1
SetTimer 3
SetWinDelay 1
Shutdown 1
Sleep 1
SoundBeep 1, 2
SoundGet 4
SoundSet 1, 4
StatusBarGetText 2
StatusBarWait 2, 3, 6
StrReplace 6
Thread 2, 3
ToolTip 2, 3, 4
TrayTip 3, 4
WinClose 3
WinKill 3
WinMove 1, 2, 3, 4, 5, 6
WinWait 3
WinWaitActive 3

This data might not be accurate.

[cyruz - guest]

I really think that this statement:

v2.0-a026 tentatively changed the behaviour so that % is always required, ostensibly because the syntax varying between parameters is a source of confusion

comply with this one:

AutoHotkey v2 aims to improve the usability and convenience of the language and command set by sacrificing backward compatibility

I think there is no convenience in something that is source of confusion, so the overall discussion for me doesn't have a point.

Sorry lexikos but I have no practical reason...

[topsoftbe]

I thought that V2 would finally bring to an end the illogical treatment of text and variables. A language where a variable had to be between %percent% signs while text didn't need "quotation" marks has always been the reason for a lot of frustration and all too common errors, for me and for lots of users.
And now you want to re-invent something like % expressions?
Please make V2 a modern language where text is between quotes, variables are just used by their names and expressions will automatically be seen for what they are.
Something like this should just work, without the need for a percent sign:

Code: Select all

Counter := 0
CurrentRecord := A_LoopFileFullPath
MsgBox, "This is a text, next is a variable: " . CurrentRecord . "now an expression: " . 125 * 5 * Counter
cmdString := "Robocopy " . chr(34) . BackupDir . chr(34) . " " . chr(34) . DestinationDir . chr(34) . " /S /E /MOVE /IS"
RunWait, cmdString
IfNotExist, DestinationDir
	{
		FileCreateDir, DestinationDir
		FileMove, BackupFile, DestinationDir . "\*.*" , 1
		Counter2 += 1
		GuiControl,, MyText2, "Files Moved       = " . Counter2 /10
	]

Text should ALWAYS be treated as such, and be between quotation marks, vars should never need a special character and there should be no need to indicate an expression. And all instructions should always be made to accept expressions.

[guest3456]

what "modern" language uses command syntax in the form of Command, params as in your example? none.

if you want expression syntax, then just use function syntax instead of command syntax. that eliminates the confusion you are talking about. thats one of the major selling points of v2:

Code: Select all

MsgBox("This is a text, next is a variable: " . CurrentRecord . "now an expression: " . 125 * 5 * Counter)
;..
FileMove(BackupFile, DestinationDir . "\*.*" , 1)

[jNizM]

End of Commands and more Functions would be nice

From:

Code: Select all

MsgBox % "Output: " VarOut
MsgBox 64,, % "Output: " VarOut
MsgBox 64, % "Title - " Name, % "Output: " VarOut

To:

Code: Select all

MsgBox("Output: " VarOut)
MsgBox(64,, "Output: " VarOut)
MsgBox(64, "Title - " Name, "Output: " VarOut)

[HotKeyIt]

Why would that be nice, how would that help anyone? If someone does not like using command syntax they can simply use functions.
All commands are available as function and vice versa, less commands would not mean more functions.
In my view a command is much easier to use for a beginner than a function, when I started with ahk it took me some time to understand functions and expressions.

Also for example that simple and very small code, in function style you would simply need to type 30 additional characters, why would you want to do that?

Code: Select all

Gui,Add,Text,w100,Test
Gui,Add,Edit,w100,Test
Gui,Add,Button,w100,Test
Gui,Show

[jNizM]

Tell me why the (in my example) MsgBox command is easier to understand than the function one?

Code: Select all

MsgBox, Text
MsgBox [, Options, Title, Text, Timeout]

MsgBox(Text)
MsgBox(Options, Title, Text, Timeout)

Your example can be looks like this (just a quick-and-dirty example)

Code: Select all

/*
Gui, Add, ControlType [, Options, Text]
GuiAdd("ControlType", "Options", "Text")
*/

GuiAdd("Text", "w100", "Test")
GuiAdd("Edit", "w100", "Test")
GuiAdd("Button", "w100", "Test")
GuiShow()