58 replies to this topic

[PhiLho]

use == instead of = in if (& as a result allow assignments in if)

I hope Chris won't do that! Talk about another source of confusion for newbies!
Note that == is already used in AHK, for case sensitive comparisons. Nobody uses it, but it is here.

I noticed AutoHotkey is based off AutoIt... correct? Is there any plans to backport the v3 version of AutoIt to AutoHotkey?

Based on AutoIt2, right.

No plan to backport: the source is no longer available. And I see no advantage to pick yet another custom made language. I don't know it, but should AHK evolve to mimick a language, I would prefer a well made one, consistent and well tested, compact but powerful and performant, like Lua or Neko or Ch for those nostalgic of C syntax...
But I doubt Chris will be so radical. He plans to continue evolutions to language, but not revolution. We don't want to throw away existing scripts, at worst to make necessary changes that would need automated adaptation of old scripts, not complete rewrite.

Com in AHK is planned, to a far and fuzzy future... This is not a topic easy to implement, I saw code just to enable drag'n'drop of text fragments between Scintilla and other Windows programs, it is a nightmare of complexity...

[polyethene]

(I) Wish AHK would...

Me too! Braces should be included in your second one though e.g. func(var) { return ... }. In addition it would be a great convenience if the single quote char ' could also represent strings. However I'm not too fond of // for comments, inline and maybe nested /* ... */ should be the only way.

[PhiLho]

Braces should be included in your second one though e.g. func(var) { return ... }.

Welcome to obfuscation clan... ;-) I already think that the one-true-brace style support was an error... :-P

In addition it would be a great convenience if the single quote char ' could also represent strings.

I see no compelling reason for that, we rarely put double quotes in strings. Why introduce more ways to break existing scripts?

OK, since everybody make syntax wishes, I would like to be able to put function calls on several lines by putting the coma (parameter separator) at the end of the line:

DllCall("Foo",
      "UInt", bar,
      "Str", gah)

[polyethene]

I already think that the one-true-brace style support was an error...

Why? Shifting one character to the line above is not a big deal. I don't see a link between reducing whitespace and obfuscation.

I would like to be able to put function calls on several lines by putting the coma (parameter separator) at the end of the line

Hmm... could cause bugs and confusion

DllCall("something",
	"Int", 32,
	msgbox, "a command name could be a variable..")

I see no compelling reason for that, we rarely put double quotes in strings. Why introduce more ways to break existing scripts?

Nearly everything new has a potential to break existing scripts. Besides, one must be pretty stupid to start a string with ' and unknowingly end it with ".

...what do you mean?...like...

You know for loops and functions where braces are mandatory... loop 100 { command1; command2; ...}, func(var) { stuff }

DAMNIT MODDELETE

Edit: oops sorry for posting before your finished JSLover, that's the answer to the question you originally asked anyway.

[JSLover]

I hope Chris won't do that! Talk about another source of confusion for newbies!

...the confusion IS AHK...every other language uses == in if...JavaScript, C...I want = for assignments...== for equals...& === for "strict equals" where a number 1 & string "1" don't match (for this I want a minimal understanding of types in AHK...like JavaScript)...

a=1             //type=number
b="1"           //type=string
if (a==b)       //true
if (a===b)      //false

Braces should be included in your second one though...

...what do you mean?...like...

if (wow="wee") { msgbox, hi! }

...braces should only be required if there is more than one command linked to the if...

...the single quote char ' could also represent strings.

...yes!...that's the spirit...I want that too!

However I'm not too fond of // for comments...

...I like // for quickie comments or nullifying some code for testing...not having to type /* */ around one line to disable it...

...I already think that the one-true-brace style support was an error...

...you are wrong...OTB is the only way!...you like rigid syntax, ok, don't try to make AHK rigid too!...there are other rigid languages to use...let AHK be...

I see no compelling reason for that...

...again, wrong...single quotes are cute!...

I would like to be able to put function calls on several lines by putting the coma (parameter separator) at the end of the line...

...yes...I would like that too...you probably know this is possible tho...

DllCall("Foo"
        ,"UInt", bar
        ,"Str", gah)

...but I do want the line continuation chars to be able to be at the end of the line too (or instead)...it looks better...

DllCall("something",
	"Int", 32,
	msgbox, "a command name could be a variable..")

...it should be..."if the function call ain't complete yet, eat lines until it is complete"...so without the closing paren of DllCall AHK would look further until it finds it...or in this case it sees the comma on the previous line & keeps adding to the DllCall...

...one must be pretty stupid to start a string with ' and unknowingly end it with ".

...yes!...we can't make the syntax protect idiots from themselves...the syntax needs to be good & flexible & if idiots can't figure it out, then they shouldn't be on a computer...

You know for loops and functions where braces are mandatory...

...ok, what is "second one though"...I think that's where I'm lost...are you saying braces should/shouldn't be mandatory?

Edit: oops sorry for posting before your finished JSLover...

...I was adding a quick edit & didn't take the time to look again cuz "surely no one replied in those 10 secs"...but then you had posted...ugh...
You posted: MonOct 30, 2006 5:20:41pm
I edited: MonOct 30, 2006 5:20:48pm...7 lousy seconds!...grrr...phpbb needs to never add that message...OR...at least not add it for 30 mins after someone's replied...still not adding it before someone's replied (regardless of time)...the 30 mins should start once there's a reply & it should warn you it's gonna add it...& even then have a checkbox to remove it!!!...

[PhiLho]

you like rigid syntax, ok, don't try to make AHK rigid too!..

No, I don't like rigid syntax, but AHK is already rigid...
And I don't like lines which are a kilometer long, just because you can put several instructions on the same line...

I already think that the one-true-brace style support was an error...

Why? Shifting one character to the line above is not a big deal. I don't see a link between reducing whitespace and obfuscation.

Because it was the first step toward "flexibility", thus toward confusing code... Plus I no longer like this style. ;-) But frankly, I can live with it, I coded lot of code for Scintilla/SciTE in this style, to stick with coding rules.

I see no compelling reason for that...

...again, wrong...single quotes are cute!...

Well, that's not a compelling reason... Neither you nor Titan explain why this is useful. Again, nothing against that, but why introduce that? If just for the sexiness of it, drop the idea. Newbies will wonder why some put ', others put ", others mix them and others just use naked (old-style) strings, if they survive the v.2.

...one must be pretty stupid to start a string with ' and unknowingly end it with ".

I don't see the point. I meant that " is currently enough, and writing "File ""%fileName%"" is empty" isn't that frequent or unreadable, so we can live with it.

... putting the coma (parameter separator) at the end of the line...

...yes...I would like that too...

Wow, sometime we agree... ;-)

Hmm... could cause bugs and confusion

Yes, the example you give would be legal, I don't see where the problem is. Either it is intended as shown, or coder has made a syntax error. No more confusing than MsgBox => Foo!

[EDIT]

...the confusion IS AHK...every other language uses == in if...JavaScript, C...I want = for assignments...== for equals...& === for "strict equals" where a number 1 & string "1" don't match (for this I want a minimal understanding of types in AHK...like JavaScript)...

Not "every other language", I can cite at least Basic and Pascal... I agree for types in AHK, but since all variables are pure strings, it is unlikely to happen soon... I believe if we have true arrays someday, this will introduce at least another type.

[Chris]

it would be a great convenience if the single quote char ' could also represent strings.

This was proposed earlier and is planned. I see the convenience of it because it avoids the need to escape lots of quotes when embedding SQL, HTML, and other languages in a script.

I would like to be able to put function calls on several lines by putting the coma (parameter separator) at the end of the line:

DllCall("Foo",
      "UInt", bar,
      "Str", gah)

In the current architecture, this is difficult to implement because line continuation is processed at an earlier stage than expressions. The two would have to be merged somehow (or cooperate better) so that line continuation can distinguish between expressions/function-calls and non-expressions.

...YIKES!...expressions & continuation sections are enemies...when I needed to write a replacement msgbox function I had to settle on this calling convention to turn off expressions for the function call...I would like most of := to be = (I think) but I need a way to turn off expressions for continuation sections...perhaps NoExp in the options (like LTrim)...

Good point. It might be a reason to have := take on the role of = rather than entirely eliminating :=. But I'm not sure yet; this will require some careful thought. I plan to start work on #v2 soon, perhaps after a few minor releases after the forthcoming RegEx release.

require parens on expression-if to allow for commands on same line...

if (wow="wee") msgbox, hi!

I don't like the idea of requiring parentheses. However, someday combining two lines into one might be supported if the user opts to use the parentheses.

I really wanna try to redo the docs someday, but I don't know if I wanna start with a blank page & add my thoughts or start editing & reformatting the existing docs...I'm certainly getting rid of that yellow bar...if favor of some other color...

With the help of John B., I've revamped the styling of documentation (including a shrinking of the yellow bar near the top of each command page). The biggest improvement is code examples, which now have better readability due to green-colored comments.

As for redoing the documentation, it's probably better to wait until #v2 because then we'll have an idea of what is going to become obsolete. The main purpose of v2 is to simplify the syntax, which consequently should simplify the documentation.

BTW...is there any reason the docs all end with .htm & not .html?

No particular reason. I realize now that .html is more standard, but I'm sticking with .htm to avoid the need for 301 redirects. Eventually, the site should probably move to omitting the extension altogether (possibly in conjunction with a dynamically-generated content based on some kind of CMS).

Thanks for the ideas.

[PhiLho]

This was proposed earlier and is planned. I see the convenience of it because it avoids the need to escape lots of quotes when embedding SQL, HTML, and other languages in a script.

No convenience here, we have continuation sections to embed other languages, otherwise it is unreadable. And since these languages already mix these two types of strings, it solves nothing: ....

entirely eliminating :=

Do that mean that the old-style string assignment will disappear? Or will it become something else like <= as I suggested somewhere else?
Somehow, I am getting used to the convenience of these raw strings, and since expression strings doesn't support variable embedding (unless using Transform Deref), we would loose some functionality.

[Chris]

No convenience here, we have continuation sections to embed other languages, otherwise it is unreadable. And since these languages already mix these two types of strings, it solves nothing: ....

It seems convenient and more readable for simple expressions such as:

; Current:
var := "<span class=""CodeCom"">"
; Proposed:
var := '<span class="CodeCom">'

entirely eliminating :=

Do that mean that the old-style string assignment will disappear? Or will it become something else like <= as I suggested somewhere else?
Somehow, I am getting used to the convenience of these raw strings, and since expression strings doesn't support variable embedding (unless using Transform Deref), we would loose some functionality.

I'm not sure what to do yet because I haven't started studying it in depth. When the time comes (perhaps in a few weeks), I could definitely use your help in deciding the nature and scope of the changes in v2 (if you have the time and interest).

Thanks.

[PhiLho]

It seems convenient and more readable for simple expressions such as:

; Current:
var := "<span class=""CodeCom"">"
; Proposed:
var := '<span class="CodeCom">'

I was waiting for this answer... Well, AFAIK, even in XHTML, var := "" is legal.
Now, I stop arguing, if you plan to introduce this string delimiter and see no ill side effect, perfect. I was mostly playing devil's advocate... :-)

When the time comes (perhaps in a few weeks), I could definitely use your help in deciding the nature and scope of the changes in v2 (if you have the time and interest).

I have. I am currently working on a proposal on true array syntax and implementation... I will show how they are implemented in JS, PHP and Lua (looking at nice, readable syntaxes in interpreted languages I know...), and we will try to get the best out of them, keeping an eye on consistency and respect of current syntax.
I know you are keen on PHP syntax of array("a", "b"). Is it because the function-like syntax would be easier to parse than JS's [ "a", "b" ] or Lua's (& C & Java) { "a", "b" }?

[Chris]

I have [the time and interest].

Good. I look forward to working with you. If you have a preferred means of collaboration (IM, e-mail, PM), please let me know.

I am currently working on a proposal on true array syntax and implementation... I will show how they are implemented in JS, PHP and Lua (looking at nice, readable syntaxes in interpreted languages I know...), and we will try to get the best out of them, keeping an eye on consistency and respect of current syntax.

Great. To implement arrays more quickly, it would be good to find out if the functionality can be divided into two parts: core/foundation and "everything else". For example, if the core functionality can be developed, tested, and documented in two weeks -- but "everything" would take two months -- that's a pretty compelling reason to start off with just the basics.

I know you are keen on PHP syntax of array("a", "b"). Is it because the function-like syntax would be easier to parse than JS's [ "a", "b" ] or Lua's (& C & Java) { "a", "b" }?

No, I only mentioned array() as a means to convert a variable from "normal" to array. Beyond that, I have no preference for array(). Also, I know little about PHP arrays other than their ability to have flexible indexes such as non-numeric strings.

Thanks.

[polyethene]

what is "second one though"...I think that's where I'm lost...

Your second wish thing:

JSLover's second wish[/url]":2qzygbda]require parens on expression-if to allow for commands on same line...

To reiterate, I agree. But it shouldn't stop there, braces should also be treated line linefeeds so code can be on the same line as them too.

I was adding a quick edit & didn't take the time to look again cuz "surely no one replied in those 10 secs"...but then you had posted...ugh...

Aww sorry dear

phpbb needs to never add that message...OR...at least not add it for 30 mins after someone's replied...

Instead they should put that edited message in the post header where the date and subject are.

No, I don't like rigid syntax, but AHK is already rigid...

Chris added OTB, plans to support single quotes and took vars in expressions into consideration. To me at least, it seems that Chris is doing a great job of improving the syntax flexibility to best suit everyone's needs. You prefer the AHK's old style which is ok, but a few more shortcuts like same line commands should do no harm, nor reduce readability.

it should be..."if the function call ain't complete yet, eat lines until it is complete"...so without the closing paren of DllCall AHK would look further until it finds it...

Yes, the example you give would be legal, I don't see where the problem is.

In my example, a message box would show or 'msgbox' could be a variable containing 'Str' and that line would be the final to the DllCall. Contrary to JSLover, I believe that using the closing parenthesis to end a statement is too ambiguous and would cause a lot of frustration and bugs.

This was proposed earlier and is planned (single quote char)

Thank you.

With the help of John B., I've revamped the styling of documentation

A couple criticisms: the blue headers are too top-heavy, I would prefer a lighter shade; second, why pink code sections? pink and green don't look great, any other light/pastel colour would do fine, light grey (#EEEEEE) perhaps? Otherwise it's great.

[Chris]

braces should also be treated line linefeeds so code can be on the same line as them too.

If I understand your meaning, that is already possible:

if true
{ msgbox 1
} msgbox 2

A couple criticisms: the blue headers are too top-heavy, I would prefer a lighter shade;

I considered that, but the lighter the shade, the less readable the text is (due to reduced contrast). However, I'm open to the suggestion of some other dark color that would look better than blue.

why pink code sections? pink and green don't look great, any other light/pastel colour would do fine, light grey (#EEEEEE) perhaps? Otherwise it's great.

The pink color (#FFF0FF) seemed to contrast best with the green comments. Other shades such as blue-gray (#F3F3FF) seem to make the text harder to read. In other words, I chose the colors that maximize contrast and legibility, but perhaps didn't pay enough attention to being stylish.

[polyethene]

If I understand your meaning, that is already possible:

I was suggesting something like if true { msgbox yes } msgbox all

the lighter the shade, the less readable the text is (due to reduced contrast).

A dark lilac (#666699) compliments the yellow command line and the blue hyperlinks.

I chose the colors that maximize contrast and legibility

Many males are colour blind so (light) red and green is not a great choice if you want legibility. Also if the colours are too contrasting and lack a satisfactory level of aesthetics many will be put off - you already know that AutoHotkey's main audience are gamers (like myself) and the casual computer user types, not programming nerds. The PHP docs use dark grey, if you didn't like my previous colour suggestion try sampling lower saturations of pink which are not so sharp: #E5CEDA, #E5DADF or #E5DFE2 for example.

[Chris]

I was suggesting something like if true { msgbox yes } msgbox all

I see. That would probably require some redesign of the parser, so it might be a while.

A dark lilac (#666699) compliments the yellow command line and the blue hyperlinks.

Dark lilac seemed too light; it reduced legibility for me in an A/B comparison. So as a compromise, I've switched to Apache.org's dark blue (#405871).

The PHP docs use dark grey, if you didn't like my previous colour suggestion try sampling lower saturations of pink which are not so sharp: #E5CEDA, #E5DADF or #E5DFE2 for example.

While those colors do look good, an A/B comparison with the current pink shows that legibility is significantly reduced. As a compromise, I lightened your #E5DADF by adding 8% to each component to get #F7EBF1 (this might not be the proper way to lighten a color). Originally, I wanted the background to be extremely pale -- in fact barely visible -- to reduce its interference with the text written on it.

Thanks.