Commands vs Functions

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

Re: Commands vs Functions

14 Jul 2016, 05:41

just me wrote:(though I don't like the idea of 'using functions as commands')
What do you mean? Would you prefer to restrict which functions/commands the command syntax can be used with, as in v1? :? It's pretty much arbitrary in v1 (or for historical reasons).
just me
Posts: 6462
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Commands vs Functions

14 Jul 2016, 08:26

I just said "I don't like it". So my answer to '...if you don't like it, don't use it ..." is "I most probably will not use it". But that's a matter of personal preferences and the syntax mix would be less confusing if all options/parameters regardless of command or function syntax would be expressions. As long as commands use the 'traditional syntax' confusion will increase.

If you still don't understand what I'm trying to say I could repeat it in German. ;)
guest3456
Posts: 2553
Joined: 09 Oct 2013, 10:31

Re: Commands vs Functions

14 Jul 2016, 11:15

lexikos wrote:Would you prefer to restrict which functions/commands the command syntax can be used with, as in v1? :? It's pretty much arbitrary in v1 (or for historical reasons).
definitely not this

lexikos
Posts: 6483
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Commands vs Functions

14 Jul 2016, 18:35

just me wrote:I just said "I don't like it".
No, you didn't just say that. You also said that. You gave two seemingly opposite opinions, which is the cause of my confusion:
"I'm not against commands"
"I don't like the idea of 'using functions as commands'"

"Using functions as commands" is more specific than "using commands" or just "commands", so I had to assume you're referring to different things.
User avatar
sinkfaze
Posts: 611
Joined: 01 Oct 2013, 08:01

Re: Commands vs Functions

15 Jul 2016, 10:57

Forgive my ignorance, particularly if this is not how you meant an answer to the questions, but I think that we should look at this a different way. Take the ControlGet command. How would you propose to retire that command and replace it with a function? A literal translation of the command?

Code: Select all

OutputVar := ControlGet(Cmd [, Value, Control, WinTitle, WinText, ExcludeTitle, ExcludeText])
Given how the language has evolved to this point (particularly with the introduction of objects/arrays), is this the most optimal method of representing that command as a function? Should the function be designed so that the user is limited to what they can grab on the frontend (one attribute at a time), or should it be designed to grab all possible attributes (saved to an object, for example) and let the user filter down to what they want on the backend? Does it constitute looking at certain classes of actions in a different way when putting them together in a function? When are there too many actions taken on by a particular function? When is there not enough?

I ran into these types of considerations when I was trying to put together my command object function library as somewhat of an update of Titan's original wrappers (six years ago (!)) and talking to others about how they used them or wanted to use them. It was exhausting for me, and I'm just a hack. I don't know if the question should be so much one of whether getting rid of them is a good idea, but more what are you going to replace them with, and how much time is it going to take you to come up with the "right" answers?

Leaving commands in place may not be ideal, but there's a significant cost to you and any other potential devs to develop an appropriate exit strategy. Is it a worthwhile cost versus the other things you could be doing? Or should there just be better documentation to let the user decide for themselves what they want and how they want it?
guest3456
Posts: 2553
Joined: 09 Oct 2013, 10:31

Re: Commands vs Functions

15 Jul 2016, 11:28

sinkfaze wrote: How would you propose to retire that command and replace it with a function? A literal translation of the command?
the translation is not a proposal, its already done. have you used v2?

https://autohotkey.com/v2/v2-changes.htm
sinkfaze wrote: Should the function be designed so that the user is limited to what they can grab on the frontend (one attribute at a time), or should it be designed to grab all possible attributes (saved to an object, for example) and let the user filter down to what they want on the backend?
its not a bad idea to return an object, but now you're forcing users to understand how to use objects as well. i think thats a larger ask than simply asking users to understand how to use functions, which in many cases is already required given that AHK v1 mixed Commands and Functions

however, some commands such as WinGet,, List now DO return array objects and other sub commands are replaced with their own. see above link. as i remember, WinGet/WinSet/Process commands that have the "Cmd,Value" have been changed. i'm not sure why ControlGet was left out

lexikos
Posts: 6483
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Commands vs Functions

15 Jul 2016, 18:57

sinkfaze wrote:Forgive my ignorance, particularly if this is not how you meant an answer to the questions, but I think that we should look at this a different way.
Ideas and opinions that I haven't already considered are exactly what I want. :thumbup:
Take the ControlGet command. How would you propose to retire that command and replace it with a function?
By replacing it with several functions, the same as I've done for WinGet. My initial idea was to merge it somehow with GuiControlGet (that is, have one set of functions covering both); I mentioned it under Commands with sub-commands:
I wrote:Rather than creating 50+ functions out of the Gui/Control/Get sub-commands, I'd like to merge the functionality of the Gui and non-Gui commands. This may help improve consistency and reduce code and documentation size. However, I'm not sure how to do it without reducing the usability of the command set with the script's own GUIs (e.g. the GuiControl commands support control names and implicitly operate on the default Gui).
However, since then I've used fincs' GUI system a bit and come to the opinion that it is much more manageable than the current system. (Merely turning sub-commands into functions doesn't make much difference.) The code duplication can be fixed without changing the interface. Aside from that, I never solved that point about usability.
Or should there just be better documentation to let the user decide for themselves what they want and how they want it?
That sounds like more work than converting ControlGet etc. to functions, even if you don't consider the need to show both ways on each page.
Given how the language has evolved to this point (particularly with the introduction of objects/arrays), is this the most optimal method of representing that command as a function?
I've had similar thoughts while looking at interfacing AutoHotkey's functionality with Lua, Python, JavaScript and .NET. Some of the commands are designed in ways that most suit the command syntax - the Gui command being the most extreme example (I think). More to the point, I'd been thinking that virtually all of the commands which accept WinTitle parameters would be better off as methods of a "Window" or "Control" object, at least for these other languages. Perhaps that would be true for AutoHotkey v2 if it has no command syntax.

You could say that the Win/Control commands encourage violating the DRY principle.
sinkfaze wrote:if there is no significant time loss to retrieve all available information about an item it may prove more satisfactory to return all data in objects in the future rather than a single piece in a variable.
Source: Command Object function library NEW [Replace functions]
It's not necessary to retrieve everything at once; you can return an object which implements dynamic properties.
arcticir
Posts: 576
Joined: 17 Nov 2013, 11:32

Re: Commands vs Functions

15 Jul 2016, 19:32

Obviously, I like the functions. but I unfortunately discovered, in V2, functions are slower than command.
lexikos
Posts: 6483
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Commands vs Functions

15 Jul 2016, 19:44

The decision will not be made based on minor performance differences within the current v2 alpha version.

Currently in v2, most commands which were commands in v1 are implemented as they were in v1, not as functions. When you call them as functions, you are really calling a stub function which simulates a command call. However, this will be changed:
As commands and functions are still internally distinct in the current v2 alpha, defining a function with the same name as a command overrides the command only for the function() style of calling; i.e. the command style still calls the original command. This should be changed.
Source: v2-thoughts
In a future release, all functions will be implemented the same way, and the "command syntax" (if present) may translate to exactly the same "byte-code" as the equivalent expression. In that case, there will be no performance difference.
hobboy
Posts: 41
Joined: 05 Jan 2016, 09:59

Re: Commands vs Functions

16 Jul 2016, 01:58

I'm in favour of just a function syntax, however I've done programming in other languages before autohotkey so function syntax familiar to me. I can't make a super thorough argument as to why I prefer this except that having one syntax is easier to deal with. I sometimes struggle with certain commands and whether I use %% around my variables (if expression mode is supported or is an output variable). I find that having an output variable in command syntax is a little unusual, like in StringUpper - this may be because I prefer to have the output variables completely separate from input variables, like on the other side of an equals sign.

I can't currently recall what commands (or maybe functions) do this, but sometimes the important result of command is stored in errorlevel rather than an output var. If command syntax was to disappear, would the function output the important result rather than place it in errorlevel, or would the output be blank?
lexikos
Posts: 6483
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Commands vs Functions

16 Jul 2016, 06:11

hobboy wrote:If command syntax was to disappear, would the function output the important result rather than place it in errorlevel, or would the output be blank?
An answer can be found in v2-changes or by calling the function with the current v2 alpha.
User avatar
boiler
Posts: 2601
Joined: 21 Dec 2014, 02:44

Re: Commands vs Functions

23 Jul 2016, 16:31

Here is an example of someone learning the language who is in their own words "very confused" as to why IfEqual, lcolor, color does evaluate to true when he knows that the value in the variables lcolor and color are the same.

I cannot see how anyone thinks it is more intuitive for someone learning the language to use IfEqual, lcolor, %color%. If someone says that is easier for novices to use, I don't think he is being honest with himself. I know the documentation shows that is the correct usage, but that doesn't mean it's easy for them to grasp.

It is much more intuitive to think that color is a variable name, and if it is to be a literal string, it needs to be differentiated from a variable name by enclosing it in quotation marks. Doesn't everyone think it would be much more intuitive if it were IfEqual, lcolor, color and IfEqual, lcolor, "blue" (and still of course IfEqual, lcolor, 0x56586C)? Even though IfEqual is superfluous and unnecessary in my opinion, it is a clear example of how traditional syntax makes the language more confusing, not less.
User avatar
tank
Posts: 2748
Joined: 28 Sep 2013, 22:15
Facebook: charlie.simmons.7334
Google: ttnnkkrr
GitHub: ttnnkkrr
Location: Irving TX
Contact:

Re: Commands vs Functions

23 Jul 2016, 17:38

I only made it about half way thru all these posts.

Much of the reasoning here is based entirely on how things were done and perceived to be easier at the time.
There is no argument to be had in my mind that the greatest source of confusion comes from the looseness of syntax that is AHK.

If your language de-references variables do it in all cases commands expressions doesn't matter.
If strings get quoted do it always.
Doing those 2 things were done the confusion on if statements with or without expressions would never happen. If those 2 simple standards were enforced we wouldnt have problems caused by the obvious confusion in outputvar:= func(%inputVardereferenced%)
I cant think of any mainstream language that allows such wiggle room. There are even plenty of situations where that syntax is appropriate.

I digress.
Commands. Like it or not they are easier for many to learn. It doesnt make sense to experienced programmers, but it is a thing. I will leave the reasoning for it to psychologists.

If we adopted no deref marks and always quote strings i think we minimize the shock and simplify the documentation challenges a bit.
NakedMyVar
"quoted Strings"

those are my random thoughts on the subject
We are troubled on every side‚ yet not distressed; we are perplexed‚
but not in despair; Persecuted‚ but not forsaken; cast down‚ but not destroyed;
https://www.facebook.com/ahkscript.org
If you have forum suggestions please submit a pull request
Thanks Tank :thumbup:
guest3456
Posts: 2553
Joined: 09 Oct 2013, 10:31

Re: Commands vs Functions

23 Jul 2016, 17:54

Tank, so are you suggesting keeping Command syntax but requiring all parameters to be expressions? If so, then whats the point of keeping commands at all?

lexikos
Posts: 6483
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Commands vs Functions

23 Jul 2016, 18:15

boiler wrote:I cannot see how anyone thinks it is more intuitive for someone learning the language to use IfEqual, lcolor, %color%.
IfEqual is irrelevant - it's already been removed in v2-alpha. That was one of the very first changes.

IfEqual and If Var = Value are mostly confusing because the left and right side use different syntax. This is because of the "InputVar" concept, which has also been removed. I think that IfEqual, %lcolor%, %color% would be easily understand by someone who has used the command syntax (or batch script). In fact, I'm fairly certain that some new users already try it that way.
User avatar
tank
Posts: 2748
Joined: 28 Sep 2013, 22:15
Facebook: charlie.simmons.7334
Google: ttnnkkrr
GitHub: ttnnkkrr
Location: Irving TX
Contact:

Re: Commands vs Functions

23 Jul 2016, 19:12

guest3456 wrote:Tank, so are you suggesting keeping Command syntax but requiring all parameters to be expressions? If so, then whats the point of keeping commands at all?
I already said command syntax is easier for non programmers to grasp.
Not exactly tho. I am saying if a variable isnot dereferenced and all strings are always quoted it will reduce confusion. I am not suggesting allowing for example string concatenation pointers or other expression like hiroglyphics move so freely into commands. Im not suggesting changing what a command can accept only how it is expressed.

msgbox "this is some string"
is easy for almost anyone to understand
that does not mean it is equivalence to
msgbox % "this is some string" . func("morenonsense")
More keep the underlying learn ability without killing us with specialized syntax rules that would never work with functions when they progress that far
We are troubled on every side‚ yet not distressed; we are perplexed‚
but not in despair; Persecuted‚ but not forsaken; cast down‚ but not destroyed;
https://www.facebook.com/ahkscript.org
If you have forum suggestions please submit a pull request
Thanks Tank :thumbup:
User avatar
nnnik
Posts: 4241
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Commands vs Functions

24 Jul 2016, 02:02

That leaves us at 2 options:

1. Removing the ability to have another thing standing with the message box:
Either
Msgbox ThisisSomeVar
or
Msgbox "This is a String"
since
Msgbox "This is a string" ThisisSomeVar
is already expression syntax.

2. Or removing Command syntax as a whole.
tank wrote:Im not suggesting changing what a command can accept only how it is expressed.
The way it is expressed defines what can be done.
Recommends AHK Studio
User avatar
tank
Posts: 2748
Joined: 28 Sep 2013, 22:15
Facebook: charlie.simmons.7334
Google: ttnnkkrr
GitHub: ttnnkkrr
Location: Irving TX
Contact:

Re: Commands vs Functions

24 Jul 2016, 11:51

nnnik wrote:Either
Msgbox ThisisSomeVar
or
Msgbox "This is a String"
since
Msgbox "This is a string" ThisisSomeVar
is already expression syntax.
No
"this is a string" is just a string not an expression
under my suggestion.% "this is a string" is still expression syntax and unless the command expects a var for a param it must still require expression syntax
msgbox % myvar
We are troubled on every side‚ yet not distressed; we are perplexed‚
but not in despair; Persecuted‚ but not forsaken; cast down‚ but not destroyed;
https://www.facebook.com/ahkscript.org
If you have forum suggestions please submit a pull request
Thanks Tank :thumbup:
User avatar
nnnik
Posts: 4241
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Commands vs Functions

24 Jul 2016, 13:44

tank wrote:
nnnik wrote:Either
Msgbox ThisisSomeVar
or
Msgbox "This is a String"
since
Msgbox "This is a string" ThisisSomeVar
is already expression syntax.
No
"this is a string" is just a string not an expression
under my suggestion.% "this is a string" is still expression syntax and unless the command expects a var for a param it must still require expression syntax
msgbox % myvar
Which would essentially remove all capabilities of dynamic coding without Expression syntax?
I mean how would:

Code: Select all

Msgbox Some Text %SomeVar%
look in your Version?
Recommends AHK Studio
User avatar
tank
Posts: 2748
Joined: 28 Sep 2013, 22:15
Facebook: charlie.simmons.7334
Google: ttnnkkrr
GitHub: ttnnkkrr
Location: Irving TX
Contact:

Re: Commands vs Functions

24 Jul 2016, 14:09

nnnik wrote:Which would essentially remove all capabilities of dynamic coding without Expression syntax?
Yes this mix has proven over and over to confuse people
msgbox % "this is a string" . somevarorfunc
If the goals is to partially reduce the confused newbs we have got to pick a syntax rule and stick to it religiously with v2
We are troubled on every side‚ yet not distressed; we are perplexed‚
but not in despair; Persecuted‚ but not forsaken; cast down‚ but not destroyed;
https://www.facebook.com/ahkscript.org
If you have forum suggestions please submit a pull request
Thanks Tank :thumbup:

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 6 guests