AutoHotkey Community

Posted: **24 Jul 2016, 16:48**

tank wrote:"this is a string" is just a string not an expression

So allow a subset of expressions but require a single percent sign at the start of the parameter for anything more complicated than a single literal value/variable? I do not see how that helps anyone. It would be more straightforward to just use expressions, and if the user only knows single values, that's what they'll use.

Posted: **24 Jul 2016, 20:45**

well i have made my case either way

Posted: **25 Jul 2016, 01:56**

Then we might as well remove commands.

Posted: **25 Jul 2016, 04:19**

I agree with that. It would simplify things even more to not have to carry both a command version and a function version and show the usage and examples of both in the documentation.

Posted: **25 Jul 2016, 05:06**

boiler wrote:I agree with that. It would simplify things even more to not have to carry both a command version and a function version and show the usage and examples of both in the documentation.

I am not agreeing with that though. I was merely pointing out that changing the input in such ways would completely remove the point of commands.

Posted: **25 Jul 2016, 05:18**

My opinion for commands vs functions (+ others) is make v2 slim and a split of old stuff:
- removing all commands where functions already exist
- move left commands to functions and remove them too
- remove support for older windows versions (min: vista / 7)

... since ahk_1.1 will be still available after final release of v2 wich support all the old stuff.

Posted: **25 Jul 2016, 07:26**

nnnik wrote:I am not agreeing with that though. I was merely pointing out that changing the input in such ways would completely remove the point of commands.

I understand why you made the comment, and I was adding that it also helps simplify the language. Do you disagree that it would do that?

Posted: **25 Jul 2016, 12:05**

boiler wrote:
nnnik wrote:I am not agreeing with that though. I was merely pointing out that changing the input in such ways would completely remove the point of commands.
I understand why you made the comment, and I was adding that it also helps simplify the language. Do you disagree that it would do that?

I say that it isn't as important as keeping it simple to learn.

nnnik wrote:
just me wrote:IMO, the mix of the two syntaxes is the most important "common source of confusion" in AHK. Commands might be easier to understand for new users without programming knowledge. But what will they imagine reading terms like 'can-be-an-expression' or 'force-an-expression'? Also, errors like MyVar := MyFunc(%AnotherVar%) are legion when they try to use functions later.
Those are issues of the current documentation not the way the program works.
Also a little confusion is bound to happen when they change syntaxes. However that could be addressed by adjusting the help file.
Due to the impression that it is easy to learn a lot of people choose AutoHotkey.
Without new people choosing AutoHotkey the language will just slowly die.
I'm not going to say that this will automatically happen if we remove commands in fact the opposite could happen.
But IMO making it easier to learn takes precedence over reducing said confusion.

Posted: **25 Jul 2016, 13:08**

@lexikos
Would removing commands make AHK significantly lighter?

something tells me not so much :/

Posted: **22 Aug 2016, 23:51**

My vote is to remove the commands, and replace with human-readable functions which have prefixed parameters unless the only parameters possible are self explanatory.

Take for example the Click command:

Code: Select all

Currently here are some examples of using Click
Click  ; Click left mouse button at mouse cursor's current position.
Click 100, 200  ; Click left mouse button at specified coordinates.
Click 100, 200, 0  ; Move the mouse without clicking.
Click 100, 200 right  ; Click the right mouse button.
Click 2  ; Perform a double-click.
Click down  ; Presses down the left mouse button and holds it.
Click up right  ; Releases the right mouse button.

By making it into a function, the syntax is cleaner, but still confusing and complex, questions will undoubtedly arise, there is too much magic going on behind the scenes:

Code: Select all

Click()
Click(100,200)
Click(100,200,0)
Click(100,200 right)
Click(2)
Click(down)
Click(up right)

I think instead it should have a paramater-prefix syntax like this, this makes it human-readable. Then, existing code becomes self-documenting. A newbie who sees a snippet of a script with the following in it, would be able to get an idea of what is really going on inside Click() without having to even read the comments or look up the documentation more than 1 time.

Code: Select all

Click() ; Click left mouse button at mouse cursor's current position. (action:lmb is default behavior when no action: is specified, current position used when no x and y specified)
Click(x:100,y:200) ; Click left mouse button at specified coordinates. (action:lmb is default behavior when no action: is specified)
Click(x:100,y:200,action:none) ; Move the mouse without any mouse button action.
Click(x:100,y:200,action:rmb) ; Click right mouse button at specified coordinates. action:rmb overrides the default action:lmb behavior.
Click(count:2)  ; Perform a double-click.
Click(action:lmb down) ; Presses down the left mouse button and holds it.
Click(action:rmb up) ; Releases the right mouse button.

Posted: **23 Aug 2016, 14:36**

Id stop developing in AHK if this would ever happen

Posted: **24 Aug 2016, 03:09**

You said keeping it simple to learn was important, is there anything about my proposal below that isn't easier to learn, I would like to know what your problems with it might be, or if you think it would work better than my last attempt

I have come up with an alternative that removes the : character below.

For that particular Click() function, I think it needs an overhaul, instead of "MouseMove" and "Click" and others there should be one super function "Mouse()",
so for example

Function:

Code: Select all

Mouse()

Parent parameters:

Code: Select all

x ; X Coordinate
y ; Y Coordinate
rx ; Relative Y
ry ; Relative X
LeftButton ; Left Mouse Button
RightButton ; Right Mouse Button
Button3,Button4,Button5, etc... ; Other buttons on some mice
Wheel ; Scroll wheel button on some mice (which can sometimes be clicked or sometimes just up/down)

Child parameters:

Code: Select all

Up ; Such as LeftButton Up
Down ; Such as LeftButton Down
Click ; Such as LeftButton Click (down and then up)
Numbers ; Such as x100 or x 100 or LeftButton Click 2

How to use:
Parent parameters may be followed by child parameters with a space or not, doesn't matter, such as

Code: Select all

Mouse(x 100, y 200)

or

Code: Select all

Mouse(x100,y200)

Parent parameters must be separated by commas, you can't have

Code: Select all

 Mouse(x100 y200)

you must have

Code: Select all

Mouse(x100, y200)

because x and y are parent parameters.
You must have one or more child parameter for every parent parameter, so you can't have

Code: Select all

Mouse(x,y100)

you would have just

Code: Select all

Mouse(y100) ; The current mouse x position would remain, only the y position would change

For x, y, rx, and ry parameters, numbers after the parameter specify pixel offsets either relative to the screen (or coordmode) (x, y) or relative to the current mouse position (rx, ry)
For LeftButton, RightButton, ButtonN, and Wheel parameters, numbers after the parameter specify the number of times to repeat the specified action, 1 is implied, so to click twice you would do

Code: Select all

Mouse(LeftButton Click 2)

Examples:

Code: Select all

Mouse(x100,y200) ; Move mouse to the specified screen coordinates
Mouse(LeftButton Click) ; Click the left mouse button
Mouse(LeftButton Down) ; Hold the left mouse button down
Mouse(Wheel Down 3) ; Scroll the mousewheel up 3 notches
Mouse(Button4 Click 2) ; Click mouse button 4 twice
Mouse(rx100, ry200, LeftButton Click) ; Move the mouse relative to the current mouse position the specified offset, and click the left mouse button at that position

Posted: **24 Aug 2016, 04:27**

The issue is not that it isn't easy to learn. The issue is that advanced developers don't like redundancies and that any user might do many more unnecssary typos - which leads to frustration and will lead to less users wanting to learn the language.
What you did is keeping the language simple but kicked simple to use out of the window.

Posted: **24 Aug 2016, 04:47**

It is different than it was before, but what is the evidence that it isn't simpler to use? It might not be as familiar to you because you already learned the old way, but that doesn't mean it's more complex to a newbie.

Posted: **24 Aug 2016, 04:56**

You didn't understand my point. It is more to type resulting in more typos more...
Any unnecassary Text within the code results in more typos more redundancies that just annoy people over time.
Also you completely forgot about expression syntax. Any user that already leaned another language completely has to rethink syntax to understand AHK.
This might be good for Hotkeys but it's bad for anything else.
How do you want to add userdefined functions. Do you have to remember every name of every parameter?

Posted: **24 Aug 2016, 07:11**

expecting a newbie to keep track of parent and child parameters being different is frankly a bit Naive. while i kinda like where your head is at here it just disregards how hard understanding parameters are to newbies. otherwise i might be one to argue for "named parameters"

Posted: **24 Aug 2016, 07:29**

a newbie already keeps track of parent and child parameters, they just aren't called that, for example
Click(up right)
"right" is really right mouse button
The newbie's brain simply does all the work as it currently is in translating, when reading or writing this code, even though both "up" and "right" are "directions", the newbie has to keep track mentally that one is an up/down behavior of the mouse button, and one is which mouse button they are talking about. Naming the parameters simply tells the newbie as he reads the code what is going on, so our brains "dont have to think", just read.

Posted: **24 Aug 2016, 07:42**

Since you mentioned a Mouse function I'll give an example.
An example of a function that is arguably the most important function for AHK.
This is how it looks in your Version:

Code: Select all

DllCall( DllFile"opengl32.dll",FunctionName"glVertex3d",Parameter1Type"Double", Parameter1Valuex, Parameter2Type"Double", Parameter2Valuey, Parameter3Type"Double", Parameter3Valuez ) ;or
DllCall( DllFileopengl32.dll ,FunctionNameglVertex3d ,Parameter1TypeDouble, Parameter1Value%x%, Parameter2TypeDouble, Parameter2Value%y%, Parameter3TypeDouble, Parameter3Value%z% )

I could go on a rant here at how this looks but I'll just leave it as is.
If you want to name parameters you can use OOP Code with getters and setters.
Henceforth I'll refer to this as cancersyntax.

Posted: **24 Aug 2016, 09:05**

How would it look now? In order to do a comparison, that is needed.. With only my side of the example, there is no way to know which is better. Also, you didn't use spaces which would help readability a lot with wordy parameters.

I would think at the very least it could look like this, but would need to see how it's actually used to translate into the new syntax
Parameters only need to be as long as necessary to contextually form the word in the persons brain, similar to how "burger" in English can be used to mean "hamburger", the context fills in the blank, like "param" in context will read as "parameter" or "val" in context of a programming language, inside a function, inside a dllfunction, will be contextually read as "value". This would save typing and also increase readability speed, see below.

Code: Select all

DllCall(file opengl32.dll, func glVertex3d, param1type Double, param1val x, param2type Double, param2val y, param3type Double, param3val z)

Syntax highlighting would help further increase reading speed, just like it already does in existing editors like Scite4Ahk

Code:
DllCall(file opengl32.dll, func glVertex3d, param1type Double, param1val x, param2type Double, param2val y, param3type Double, param3val z)

Also, for user-defined functions, you can't use them without knowing what parameters you're passing are anyway, and people reading the function don't know what those parameters do without looking in the function, unless they are self explanatory. If they are self explanatory, you don't need a parameter name to prefix that parameter. If they aren't, naming them helps in the proper use of the user-defined function as well as reading the function later to understand what it's doing to some extent without looking in the function.

For example the new function Mouse(), if it was a user-defined function, has the option to Click and the option to specify x and y coordinates, from this syntax Mouse(x100,y200,LeftButton Click) we can infer exactly what the function is doing without looking in the function code itself. If we type Mouse() a good IDE like Scite4AHKv2 should look up if that function exists, and display all the possible parameter names like "x" and "y" and "LeftButton", etc. along with the child name options after you type a parent. This isn't needed, it simply avoids having to look inside the function to know the names. The way it is now, you have to either memorize the parameters for functions and what they signify, or look in the function as well, or it's self explanatory and simple (like the math functions). In v2, the self explanatory functions like abs() obviously wouldn't need a parent prefix.

Posted: **24 Aug 2016, 11:24**

as tank said, you basically are asking for Named Parameters
https://en.wikipedia.org/wiki/Named_parameter

But this thread is not about changing the existing function syntax. Start a new thread for that ~~horrible~~ idea

AutoHotkey Community

Commands vs Functions

Re: Commands vs Functions

Re: Commands vs Functions

Re: Commands vs Functions

Re: Commands vs Functions

Re: Commands vs Functions

Re: Commands vs Functions

Re: Commands vs Functions

Re: Commands vs Functions

Re: Commands vs Functions

Re: Commands vs Functions

Re: Commands vs Functions

Re: Commands vs Functions

Re: Commands vs Functions

Re: Commands vs Functions

Re: Commands vs Functions

Re: Commands vs Functions

Re: Commands vs Functions

Re: Commands vs Functions

Re: Commands vs Functions

Re: Commands vs Functions