Sign In
Create Account
Last active: Jan 02 2012 10:09 PMSo it expresses only ideas I have on what this v.2 should be, although I believe some of the ideas here were expressed by Chris (or others).
This topic is open for discussion, of course.
First, a bit of history, it might help to understand the need for a v.2.
In prehistoric times, there were AutoIt 2, a scripting language for Windows whose syntax was more or less batch-like, setting values in the environment to manage "variables", having only the most primitive operations (Add, Sub, Mult, Div), with a rigid syntax (easy to parse) of command followed by parameters.
To do more complex computations, you had to use an external program!
Then, Chris created AutoHotkey based on AutoIt 2 syntax, to keep a compatibility with hundred of scripts, compatibility that was dropped by the AutoIt team.
The above limitations being annoying, he improved the syntax, introducing expressions.
To keep compatibility, he made a second syntax, using := to assign the result of an expression, and parenthesis around the condition of an If to evaluate it like an expression (with annoying exceptions...).
It was a good thing, but with time, it proved to be very confusing to newbies, that wrote stuff like:
a = b * (c - d) x = %y% + %z% If val = var - 1 If (%a% = %b%)and so on...
So, one of the main motivation for the v.2 is, AFAIK, to simplify and make consistent this syntax, at the cost of dropping the original compatibility with AutoIt 2.
Note that the later isn't any more a must have, old AutoIt 2 scripts are probably long forgotten and obsolete, and the number of AutoHotkey scripts is probably much bigger!
Some people fantasied and proposed more changes, so AHK would look more like their favorite programming language (often JavaScript...).
Chris made clear that he wants to keep the changes to a minimum, to avoid unnecessary fluff and to keep the original flavor of AHK.
Other people seems to find AutoHotkey easy to learn and to use due to old syntax, ie. lack of quotes around strings, of parentheses around command arguments, etc.
So let's try to walk the thin line between those opposed goals.
Note I propose NOT to discuss here major new features, like improvement of API structure support or true arrays, as they already have their own topics.
So, let see these two tripping syntax differences.
Following Chris (IIRC), I propose that in v.2, = acts like :=, ie. it expects an expression on the right.
So a = It's cool would generate a syntax error message.
Perhaps := would be kept as is, to ease the transition, but discouraged.
Now, I believe we should keep literal assignment, as it is convenient, and I like the dereferencing.
To avoid any ambiguity, it could have a very different symbol, so there would be no ambiguity by using it.
I propose to use <<. It is graphically explicit, and would please Unix (and perhaps Dos) users, and C++ programmers too (stream-like syntax...).
a << ; Set var to be empty s << Quickly set a long string (auto-trimmed) %refToVar% << Result: %res%`n(%nb% lines)I propose that, since there is no ambiguity at all (no command possible on the same line), that If is always followed by an expression, even if there is no parentheses.
If a = y - x
If bCond1 and (bx or by)
If foo >= bar { ; For those liking the OTB
If (c >= 0x41 && c <= 0x61) ; Parentheses can be there in all cases
Making the parentheses optional is, I believe, in the spirit of AHK, by not forcing to use symbols that are not needed. Simpler, faster to type, flexible.Other points that have been discussed:
- Drop the obsolete convention that space is a concatenation symbol in expressions. Let the space-dot-space be the official and only symbol. Here again, too much possibilities are confusing, and the old convention proved to bring ambiguity and bugs.
- A symbol to allow to allow putting several commands on the same line.
It is not obvious, because lot of commands take a "naked" string as last parameter, and such a string can end with any symbols. So I proposed to allow such separator only to separate expressions. And Chris proposed to use the comma to this end.
This is a good idea: it has already a special meaning as separator, has no meaning in expressions, and is separator in C/C++ too.
- Make deprecated a number of commands that proved to be unused by most people, of obscure meaning, or that have been obsoleted by expressions.
They would live in some versions, then would dissappear. That would make the binary smaller, the manual lighter and less intimidating. In the interim phase, they would be banished in common purgatory page, so curious people could still find them if meet in a script, but the manual would be still simplified.
No exhaustive list yet, but good candidates are the compound If (IfEqual, IfNotEqual, ...), the primitive operations (EnvAdd, EnvSub, ..., retaining the special += and += seconds), some directives changing behavior of scripts, most Transform commands which are replaced by functions, etc.
I would like also to remind an old wish: to concatenate strings to the end of a variable, a very common operation.
var .= result . "`n" res <<< result`nOK, that's all for now, but I might come back to augment this list, and you can, too!
Back to top
