commands and commas

Discuss the future of the AutoHotkey language

How should initial commas in commands be treated?

We should force initial commas.
2
12%
We should force no initial commas.
9
53%
We should allow both (I prefer initial commas).
4
24%
We should allow both (I prefer no initial commas).
2
12%
 
Total votes: 17
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: commands and commas

07 Nov 2017, 14:05

@just me:
That is, a "command" is now just a function or method call which sits at the start of the line, lacks parentheses and discards its return value.
I interpreted this as:
A "command" is now just a function or method call which lacks parentheses, but that may or may not accept/enforce an initial comma depending on what decision is made.
rather than taking it exactly literally to mean:
A "command" is now just a function or method call which lacks parentheses.
So to me, that's taking things too literally.

@Helgef:
commands are gone, there shouldn't be any talk about commands
I would describe it as:
commands have changed, it's fine to talk about commands
Commands now use function-style parameters, and have function equivalents.
(We have what you could call 'fummands' or 'conctions', they can be written in 2 ways.)

So to me, that's being a bit too literal about what a command is.

@guest3456:
so really i'm fine with it as-is
If you're fine with it, that pretty much seals the deal for me. It's when you expressed some disquiet over this, that that made me feel the question should at least be discussed, not that I expected or necessarily wanted the outcome to change.

This will be fine if you enforce the space, as is the current rule.
MsgBox 1,2 ;MsgBox(1,2)
MsgBox ,2 ;MsgBox(,2)
Always require parens ()
I'm neutral on this, other people are welcome to start a new poll. To me it's a separate question. I won't start this poll myself, I think it's a great question though.

@all:
This script uses a mix of both initial commas and no initial commas:
Window Snapper - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=6&t=39566
I find the no initial comma style objectively uglier, I find it hard to imagine any human being who would say that the no initial comma style looks better. Beauty is often subjective, but some aspects of beauty are objective, shared throughout nations and cultures. It doesn't matter so much for 1-parameter commands/control flow statements/directives however. In the final analysis with all things considered, I'm ready to accept forcing no initial commas for AHK v2, but it's not a decision to be taken lightly, also, I would say it is the single biggest change to the language.

My main interest now is recreational, I would like people to state which they find more aesthetically pleasing, long commands with/without an initial comma. Elegance is important in programming, and it's one of the reasons I like AutoHotkey over other AutoXXX languages.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
just me
Posts: 9426
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: commands and commas

07 Nov 2017, 16:40

Removed legacy command syntax and %expression% substitution in strings.

That is, a "command" is now just a function or method call which sits at the start of the line, lacks parentheses and discards its return value.
What more do you need to get it?
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: commands and commas

07 Nov 2017, 17:03

- Do commands exist in AHK v2? My answer? Yes.
- Commands are similar to how they were in AHK v1, but the parameters now use function syntax. Also, all (or most) commands have function versions, and all (or most) functions have command versions.
- So my use of the word 'command' is fine, and uncontroversial, I don't know why people are bringing this up.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: commands and commas

08 Nov 2017, 01:48

jeeswg they are not commands - which is just mes point. They were only called commands so far for a lack of better name.
Recommends AHK Studio
SirRFI
Posts: 404
Joined: 25 Nov 2015, 16:52

Re: commands and commas

08 Nov 2017, 04:15

guest3456 wrote:Always require parens ()
This ↑
Having few coding "methods" may be confusing and causes code inconsistency. Isn't removing the issue one of AHK 2 goals?
Use

Code: Select all

[/c] forum tag to share your code.
Click on [b]✔[/b] ([b][i]Accept this answer[/i][/b]) on top-right part of the post if it has answered your question / solved your problem.
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: commands and commas

08 Nov 2017, 14:53

jeeswg wrote:I interpreted this as
jeeswg wrote:I would describe it as:
people already have explained how you are "interpreting" and "describing" things incorrectly

jeeswg wrote:- Do commands exist in AHK v2? My answer? Yes.
your answer would be wrong

jeeswg wrote:Also, all (or most) commands have function versions,
no.

jeeswg wrote:and all (or most) functions have command versions.
not exactly. they have command-like syntax by simply allowing you to omit the parens, and discard the return value. thats it.

jeeswg wrote:So my use of the word 'command' is fine, and uncontroversial, I don't know why people are bringing this up.
no. your use of the word 'command' is flat out incorrect. and therefore you are bringing the controversy upon yourself

jeeswg wrote: @guest3456:
so really i'm fine with it as-is
If you're fine with it, that pretty much seals the deal for me. It's when you expressed some disquiet over this, that that made me feel the question should at least be discussed, not that I expected or necessarily wanted the outcome to change.
ultimately i still think this leads to more confusion, not less. that's why i'd rather just always require parens. but i do understand that the nature and history of AHK is important, and the command syntax is a staple. i do think this is a worthwhile discussion, but i think lexikos has already made his decision since he never really asked for opinions on this. i dont have a strong opinion on it

allowing both initial comma and no initial comma, you would have to enforce a "no space before initial comma" rule to differentiate between these:

Code: Select all


msgbox, 1, 2    ; msgbox("1", "2")
msgbox 1, 2     ; msgbox("1", "2")
msgbox , 1, 2   ; msgbox("", "1", "2")   or   msgbox("1", "2")   ?		

User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: commands and commas

08 Nov 2017, 16:27

SirRFI wrote:Having few coding "methods" may be confusing and causes code inconsistency. Isn't removing the issue one of AHK 2 goals?
- I'm not sure what you mean here. If we only have one way of doing things, and not two, that should make things simpler.
- So that's an argument to scrap command-style parameters (done), scrap allow initial commas (done), and potentially (I'm not for or against this, by a nudge I'm probably in favour, but it's a toughie) scrap commands.

Clearly what I was saying re. just me, was not re. what a command is, but simply that the quote implies that: functions will have a command version, yes, without parentheses, yes, with/without an initial comma, the comment doesn't specify. I don't interpret it as saying that initial commas will definitely be disallowed.

Re. Helgef, I am saying that commands in AHK v2 half-exist. It's not hard to find something in AHK v2 that is quite command-like.

The quote uses the word 'command' in quotes.
All I'm doing is dropping the quotes, let's put them back in.
- Do 'commands' exist in AHK v2? My answer? Yes.
- 'Commands' are similar to how they were in AHK v1, but the parameters now use function syntax. Also, all (or most) 'commands' have function versions, and all (or most) functions have 'command' versions (i.e. command-style syntax versions).
- So my use of the word 'command' is fine, and uncontroversial, I don't know why people are bringing this up.

Re. commands v. functions:

Code: Select all

;AHK v1:
Cmd var, text ;a command
Cmd % var, % "text" ;a command
;AHK v2
Cmd var, "text" ;not a command? sort of a command?
- I would call Run(Path) a function, and Run Path the command version of the function. Is it OK to at least call it that?
- What I'm hearing is that the thread shouldn't be called 'commands and commas' because AHK v2 doesn't use commands any more, the thread should be called 'command-style notation for functions, control flow statements and directives, and commas', would that title make everybody happy?
- What I would call the Run command in AHK v1, I would call the Run function in AHK v2, whether presented in command or function notation. However, if someone were to call it a 'command', is that cause for hysteria?
- To be honest, you could equally say that AHK v2 has moved everything to be commands only, with function versions of each command available, and you shouldn't call anything that looks like an AHK v1 function, a 'function'. I don't agree with that, but that is equally as pedantic as some of the talk I've been seeing.
- Btw although I'm steering clear of calling anything in AHK v2, a 'command', if it looks like a command, and acts like a command, then ... perhaps it's a command.
- For someone to say you can't call what looks like a command in AHK v2, a 'command', is one thing, but to say that commands have been removed from AHK v2 is odd, they have survived and they have evolved.
- So I would say that conceptually commands don't exist in AHK v2, and conceptually commands do exist in AHK v2.
- And that's the argument, that conceptually you shouldn't call it a command, but by nature it is a command. So the use of the word command is always half-right and half-wrong, it's hard to be in full agreement with the pedantry.
- Anyhow, I made arguments that backed up my statements.

Btw AutoIt used function notation, did it not? So Chris introduced two styles of command, re. initial commas, which is quite interesting if it's the case.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
derz00
Posts: 497
Joined: 02 Feb 2016, 17:54
Location: Middle of the round cube
Contact:

Re: commands and commas

08 Nov 2017, 22:46

@jeeswg

jeeswg wrote:I would call Run(Path) a function, and Run Path the command version of the function. Is it OK to at least call it that?
The conflict you are encountering with this is due to terminology only. The question "Is [this] OK?" is worthy of another thread. What you mean by "scrapping commands" is, if I have it right, what the others are meaning by "force using () around builtin function parameters.

Let's come up with a concise (some of the above posts mock conciseness) definition for the term "command". Here's my go at it. Can you try the same thing of what you think it should be?

command: (1) In AutoHotkey 1.1, a "keyword" with predefined parameters, all separated from the command name (optionally) and each other with commas. Literal text is not enclosed in quotes, and variables are declared inside %'s, unless "force expression syntax" method is used (2) In AutoHotkey v2, a temporary, debatable term for a function without parentheses. [Source: my brain, posts above by nnnik, Helgef, etc]

Let's throw in one for "function" too for good measure. Don't mention it, yes I am [not] good at writing dictionaries.

function: (1) In AutoHotkey, a "keyword" with predefined parameters, the parameters are enclosed in parentheses, and all use expression syntax. In AHK v2, all what were builtin commands in 1.1, are builtin functions.
try it and see
...
User avatar
derz00
Posts: 497
Joined: 02 Feb 2016, 17:54
Location: Middle of the round cube
Contact:

Re: commands and commas

08 Nov 2017, 23:10

I don't know much about programming, and have very limited experience. But I do know that if I am editing a script in Notepad, there are many things I am not quite sure about, because I miss an IDE's highlighting, parameter call-tips, auto-completion, etc. Also, I can see now that guest3456 and others have discovered an even greater ambiguity with allowing commas before the first parameter in functions without parentheses.

Basically, looking at it as objectively as I can, what I would say if a developer asked me (which he wouldn't unless he was crazy lol) is: Please let's have some standard format, maybe it doesn't need to be quite as strict as Python, but have a standard well illustrated in the docs. In this particular situation, initial commas were optional with commands. In v2 these are functions, so a comma is out of place, because functions only use commas between parameters.

As nnnik says he likes initial commas, and you do, I assume there is a reason. there is something about the command syntax that makes AHK v1.1 unique, and might be to the prolonging of its days. But the decision was made years ago to remove that type of syntax for v2*, and so all commands are builtin functions, and also you can leave off the ()'s if you don't want a return value. Whether or not the ()'s should be optional has already been decided, but maybe could be changed, let's vote on that for kicks.

* The point of developing v2 is anything but to improve v1.1. It is a different branch. Simple, cold, and clear.

Good night every one. I might regret these posts in the morning. But I don't know that for sure yet.
try it and see
...
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: commands and commas

09 Nov 2017, 06:41

@Helgef: Re. 'Respecting'. Just noticed the edit, hilarious, cheers.

@derz00: I didn't really want to say anything in this thread, just to hear if anyone actually thought that the no initial comma style was aesthetically pleasing/aesthetically acceptable, and perhaps bring in references to other programming languages. I was also generally interested to hear any comments I hadn't anticipated or any passion for keeping one over the other.

Btw Helgef started by saying commands had been removed. But I think a lot of people would take that statement to mean 'command-like syntax for functions has been dropped', rather than the weaker 'conceptually commands don't exist more, what looks like the old AHK v1 commands are actually an alternative syntax for functions'.

There is a choice of two styles. I've accepted that initial commas could go completely (i.e. to keep the AHK v2 handling of spaces/tabs and commas exactly as it is now). The main arguments for it are: aesthetics, consistency, readability.
Here are two lines from WindowSnapper.ahk. I find the former to be aesthetically pleasing and more readable.

Code: Select all

;with initial comma
WinGet, minMax, MinMax, ahk_id %id%
GetKeyState, leftButtonState, LButton, P ; state will be 'D' if Left Mouse is down or 'U' if it is up

;with no initial comma
WinGet minMax, MinMax, ahk_id %id%
GetKeyState leftButtonState, LButton, P ; state will be 'D' if Left Mouse is down or 'U' if it is up
This example shows the initial comma style is actually more consistent with functions, if you count the separators.

Code: Select all

Cmd, Arg1, Arg2 ;Cmd SEPARATOR Arg1 SEPARATOR Arg2
Cmd Arg1, Arg2 ;Cmd Arg1 SEPARATOR Arg2
Cmd(Arg1, Arg2) ;Cmd SEPARATOR Arg1 SEPARATOR Arg2
The main argument against the initial comma style is that you have to type more commas.

Code: Select all

Sleep, 1000 ;do we really need a comma for commands?
Another argument is that there are inconsistencies in the documentation about when commas should be used, relating to commands, control flow statements, and directives.

@derz00: You messaged me with some interesting points, I'll respond here:
- This thread was meant to be about new information not about old arguments, so me providing some links to other threads, was partly to give 'value for money' for anyone who invested time in reading a thread that was otherwise lacking in content. Plus, I know that just me was away for a while. Plus, I did not expect anyone to reply about those links directly, if they wanted, they could reply in those threads.

'Conflict' is a bit of a strong word, some people responded in a somewhat of a blasé, assuming manner, and actually gave potentially misleading information. Sometimes this could be a language barrier issue. I responded in kind, in a somewhat needling way, but it was meant to be friendly and good-humoured. I haven't had one of these more fierce threads in quite a while.

Looking back, everything was going fairly well until one user bluntly said: add another option (presumptuous and facile and avoiding the tough decision, plus if he cares so much he should have the character to start a thread on it, but yet goes on to challenge people for starting threads), other programming languages are irrelevant (it's always worth looking at other ideas), the decision has already been made it's 100% decided (the word 'revisit' was used), I question your motives in starting this thread (oh rly?), should every change be discussed (should nothing be discussed, is it such a problem?), what are the advantages (they'd been previously addressed). Every comment there is vacuous and borderline provocative, in isolation harmless, but as a group less so.

That's all quite harsh, but I find it rather enjoyable to read, and don't mind responding in kind. It's by a valued member of the forum, and I'm fine with things being said in a strong way rather than a weak way.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
SirRFI
Posts: 404
Joined: 25 Nov 2015, 16:52

Re: commands and commas

09 Nov 2017, 07:39

Imagine You are new to AHK, maybe even to programming/scripting/whatever. One of main issues You encounter with AHK 1 is how different the code may look depending on what command/function it is. Examples:
Command OutputVar, LiteralText
Command, OutputVar, LiteralText
Command, OutputVar, %InputVar%, % InputVarOrExpression
Function(InputVar, %AnotherInputVar%)
As result, many people mess/mix these things, achieving undesired effect.

Now that "commands" are gone in AHK 2 - everything is expression, so no need to do %InputVar% (unless that de-ref thing) or force expression. That's one issue less, but still not all of the mentioned above. People may still wonder when to use comma after the "command"/function name (which is the topic of this thread) and when to use parentheses. In other words, user may think what is the difference between Something Arg, Arg and Something(Arg, Arg) - the answer is no other than just syntax, is it?

That being said, I think only Something() should be allowed - for consistency, maybe it will be easier for AHK to understand (parse?) and perhaps even allow to expand the possibilities, like multi-line function call without using . every line or something.
Use

Code: Select all

[/c] forum tag to share your code.
Click on [b]✔[/b] ([b][i]Accept this answer[/i][/b]) on top-right part of the post if it has answered your question / solved your problem.
User avatar
derz00
Posts: 497
Joined: 02 Feb 2016, 17:54
Location: Middle of the round cube
Contact:

Re: commands and commas

09 Nov 2017, 08:39

jeeswg wrote:This example shows the initial comma style is actually more consistent with functions, if you count the separators.

Code: Select all

Cmd, Arg1, Arg2 ;Cmd SEPARATOR Arg1 SEPARATOR Arg2
Cmd Arg1, Arg2 ;Cmd Arg1 SEPARATOR Arg2
Cmd(Arg1, Arg2) ;Cmd SEPARATOR Arg1 SEPARATOR Arg2
Can you clarify what is more consistent?

I only see that a , cannot replace a (, because there is no closing character for a , like ), and because , is used to separate parameters.

However, a space works to replace the ( because spaces are not used to separate parameters.
try it and see
...
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: commands and commas

09 Nov 2017, 15:13

@derz00: People often say that the no initial comma style is more similar to functions (functions without the brackets), but against that, the initial comma style is more similar to functions because you have a visible character separating the command name and the first parameter.

@SirRFI: Wow, put starkly like that, it does help to make the case for scrapping commands. Perhaps we should scrap commands.
- It would help writing examples in the documentation, re. which style to present, command-style and/or function-style.
- It would help when you suddenly want to retrieve the result of a 'command' when previously you didn't need it.
- It would avoid user confusion re. why are there 2 ways of writing functions.
- It would avoid user confusion re. how do we handle commas.
- It would help simplify the task for the main devs of completing AHK v2.
- When AHK v3 is being written people will be saying, OK let's finally get rid of 'commands'.
- The only drawback of using functions solved:

Code: Select all

:*:slx-::Sleep(){Left}
:*:sl1000-::Sleep(1000)
- If people can goad me into it, maybe I'll start a two-option poll re. scrap commands completely.
- Anyhow, what's on-topic in this thread has now shifted. Feel free to make arguments for/against whether 'commands' should be scrapped. Also feel free to suggest the title/questions/answers for a poll.
- Can you do two polls in one thread, or do you need a new poll? I don't want to change the options for this one, because it would dilute the power of both the current question and the new question.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
derz00
Posts: 497
Joined: 02 Feb 2016, 17:54
Location: Middle of the round cube
Contact:

Re: commands and commas

09 Nov 2017, 15:32

OK. You haven't clarified it. Sometimes a visible character is more confusing than invisible. But whatever, I'll won't repeat what has already been said.
one user bluntly said: the decision has already been made it's 100% decided (the word 'revisit' was used)
Are you quoting Lexikos with 'revisit'? If so, it is from
here. wrote:Parse, Read, etc. are not parameters any more than Loop or in are parameters. There is dubious benefit to requiring quote marks or allowing variables/expressions for the sub-command. (As for requiring, allowing or not allowing the comma, I had deferred thinking about it as I was losing interest and approaching the end of the weekend. It is in my notes to revisit.)
To repeat what has already been said, the context here is not about functions-without-parentheses. It is about control flow statements, especially Loop Parse etc.
try it and see
...
just me
Posts: 9426
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: commands and commas

10 Nov 2017, 04:11

For all who didn't read it as yet:
v2.0-a079-be5df98 wrote:The Big Changes

Removed legacy command syntax and %expression% substitution in strings.

That is, a "command" is now just a function or method call which sits at the start of the line, lacks parentheses and discards its return value. Aside from parentheses, commands and functions now share the same syntax. In general, functions with a single return value do not use an output variable, so usually require parentheses to be useful. See v2-changes for details.

Source
v2-changes wrote:Removed "command syntax". That is, a "command" is now just a function or method call without parentheses (at the start of a line). That means:
  • All former commands are now functions (excluding control flow statements).
  • All functions can be called without parentheses.
  • All parameters are expressions or output variables, so all text is "quoted".
  • Parameters are the same regardless of parentheses; i.e. there is no output variable for the return value, so it is discarded if parentheses are omitted.
  • Normal variable references are never enclosed in percent signs. Use concatenation or format() to include variables in text.
  • There is no comma between the function name and parameters, so MouseGetPos(, y) = MouseGetPos , y (x is omitted). A space or tab is required for clarity.
  • There is no percent-space prefix to force an expression.
  • Commands which previously accepted an "input variable" now also accept other expressions.
  • Method calls are restricted to a plain variable followed by one or more identifiers separated by dots, such as MyVar.MyProperty.MyMethod "String to pass".
Source
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: commands and commas

10 Nov 2017, 06:23

@just me: Many thanks for the second link. I forgot about this page:
v2-changes
https://autohotkey.com/v2/v2-changes.htm
Because it's been a little while since there were changes to AHK v2. Fingers crossed.

[EDIT:] Wow, lexikos added a note at that link about this:
•Ternary operator with less than three operands.
I had been saying that it should be mentioned somewhere. Thank you lexikos, you do spoil us.
(So my 2 key concerns re. undocumented changes have now been addressed.)
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: commands and commas

02 Jan 2018, 03:02

I prefer the initial commas, because it helps with readability. The use of brackets never bothered me, as it was still very clear when dealing with functions. However, the "initial space" style is quite unsettling. I suppose it's about locking in on "key words". The comma helps do that, and it separates information.

Return to “AutoHotkey Development”

Who is online

Users browsing this forum: No registered users and 22 guests