v2-thoughts Discussion

[Flipeador]

Due to If (TRUE), MsgBox() shows an error, If (TRUE) {MsgBox(1), MsgBox(2)} would be fine. Or am I missing something?...
BTW, Good job

[lexikos]

Once again, this topic is not for general discussion of v2 or help requests. There are whole forums for that.

I have split this post into its own topic (which could just as appropriately have been posted in Ask for Help).

[bourdin07]

AHK v1.30 will still maintained or dead when v2 will released ?
Too many changes breaks my programs

Personnally I don't care of changes on Object v2... Object work fine in v1.1.31, AHK v1.1.* work fine
The most important is to implement Gui object in v1 and change syntax to remove % on method such as MsgBox % ...

[knn]

I am by no means an AHK expert, but for v2 I would like to have $variable names, i.e. names which start with a $. Simply allow it as a normal character (like in Javascript) or as a mandatory prefix (like in PHP).

That way one can program syntax highlighting better (UDL files for Notepad++).

Also I would like to see ; at the end of the line. AHK has already ; as comments but v1 does not allow x := y; because it demands a space before the ;

[TheArkive]

I just wanted to say that I'm quite happy with the development of AHK v2 so far. I find these specific changes to be quite helpful:

• The Type() function, and the more specific data types in AHK v2 make it easier to handle specific types of data, because they can be detected as their type more easily.

• The new GUI object is amazing! With the ability to operate directly on the HWND of a TreeView or ListView, or to be able to easily get the text AND index of list-type controls, my code is better structured and more readable. It's also nice to not need to rely on DLL calls and additional libraries in order to accomplish these things.

• The new syntax for the changed commands is quite helpful in being able to put more elements of code "inline".

• There have also been a few instances where the handling of COM objects has been noticeably faster as well. I adapted @SKAN's Filexpro() for AHK2 and managed to get better performance out of it.

I'm afraid I don't have enough programming knowledge to comment on much of what the "big devs" are discussing in this thread and other threads, although I can say that I have understood probably over 50% of those discussions, and so far I have found the AHK v2 documentation (for a108) quite sufficient for the sake of learning not only AHK v2, but also gaining a deeper understanding of object usage, and the differences between the fundamental object types. The new capabilities of the GUI object motivated me to dive deeper into classes, and now I'm able to understand classes better as a result.

Just wanted to say thanks to the "big devs" and keep up the good work! I feel closer to "real programming" than I've ever been, and hopefully some day will make the leap to C++ (assuming my brain doesn't explode in the process).

[lexikos]

I updated v2-thoughts.

[jNizM]

Constants sounds nice.

btw. shouldn't it now rather be https://www.autohotkey.com/v2/v2-thoughts.htm (and yes. there is a redirect atm)

[lexikos]

I copy-pasted from the top post. I could have left it without a link...

[Helgef]

Although I'm not sure I've ever seen a case where dynamically creating variables was the best solution to a problem

I have used dynamic variable creation for repeated string concatenations, which performs (or at least did at the time) much better than using array/map. Ofc, that wouldn't be a reason to enable dynamic variables rather than optimising arr[x] .= ....

[lexikos]

If the script could be refactored to use a non-dynamic variable, that would be more efficient. I suppose that might not be possible.

I intend to experiment with alternative string representations once it becomes easier (i.e. after doing a lot of house-cleaning in the code base). I do not wish to make language choices based on how the current implementation performs.


I didn't mention it in v2-thoughts, but I've started refactoring script2.cpp, which has become far too large and disorganized. I'm having to jump through hoops to preserve the line history as seen by git blame, due to multiple issues with how git works. Raymond Chen's blog was instrumental in getting git to do what I want.

My next step will probably be to start experimenting with using metadata to create function objects that call native functions, initially limiting it to types used by the built-in functions. I will use this to allow the built-in function signatures to be converted to more natural C++ syntax, where all parameter conversion and type validation is handled centrally. For the short term, this will fix issues with inconsistent parameter type validation. For instance, while writing test cases I found that MonitorGet(&left, &right, &top, &bottom) wasn't initializing one of the variables. The reason was that I missed the N parameter, which should be Integer but is being passed a VarRef.

For the longer term:

• It will facilitate automatic coercion of objects through methods such as ToString(). This isn't done yet because of the cost of implementation with the way parameters are handled at the moment.
• Eventually the code can be expanded to handle more types and calling conventions, making it a replacement for DllCall. This would give the language higher-level support for external libraries, allowing syntax and performance closer to built-in functions.
• Optimizations to how the function objects are generated would apply to both built-in functions and external functions.
• Perhaps some of the code could be reused to give script functions parameter type validation.

[iseahound]

Did you mention improving the parser at some point?

I wonder if function statements can be special cased to handle the postfix ? and * better.

Code: Select all

MsgBox ["deref_me"]*
; EOF marker works.

Code: Select all

MsgBox ["deref_me"]*
if (1 + 1 == 2) ; fails as * begins a continuation section.
   MsgBox

It just feels to me that parsing has gotten very ambiguous with prefix / infix / postfix operators and continuation sections - perhaps something a little stronger is needed to keep things clear.

[lexikos]

If you have an idea or question that does not directly relate to this (v2-thoughts) topic, and still think it warrants discussion after reading this post, start a new topic.

If you want clarification about something that I have written in v2-thoughts, this topic is the appropriate place to post.

I wonder if function statements can be special cased to handle the postfix ? and * better.

This would not be an improvement, nor would it be backward-compatible.

It just feels to me that parsing has gotten very ambiguous with prefix / infix / postfix operators and continuation sections

There would be more ambiguity, not less, if I implemented your suggestion.

A function call statement cannot (legally) be variadic or literally end with var?.

Function call statements cannot be variadic; that is, the parameter list must be enclosed in parentheses (or brackets for a property).

The question mark must be followed by one of the following symbols (ignoring whitespace): )]},:.

perhaps something a little stronger is needed to keep things clear.

I have no idea what you mean.