Some beta eve preparations

Discuss the future of the AutoHotkey language
arcticir
Posts: 694
Joined: 17 Nov 2013, 11:32

Some beta eve preparations

01 Jun 2021, 17:55

1. Code formatting tools
I read the "Scripts and Functions" partition completely a few days ago, but I didn't find any post related to formatting code. I use an old IDE, EmEditor, which is simple and easy to use, but the code written is very messy. I really need a formatting tool to help me organize my code, especially after I came across the fmt tool of rust language - rustfmt, I think ahkfmt is the most urgent thing we need.

2. standard library
I am a user of version H. Version H comes with its own LIB folder, which is really useful. I think we should implement at least the basic standard library in the beta version. For example, json, zip, object-view, gdip, http, this will save a lot of work for newbies.
Also I would really like to have json functions built in. json is the most popular data format that most advanced users of ahk will use. ahk has poor performance, and it would be a huge benefit if it were implemented internally in C++. And v2's arr-map is fully compatible with json.
It is similar to the "LoadPicture" function (not a core function), which I have never used, but I use json frequently.

3. can't we really change the name of "VarSetStrCapacity"?
Do we really need such a long name for a core function that is used frequently? Several modern languages I've worked with have very concise names for their built-in functions, while older languages are a bit more lengthy. For example, lua's command to define a function is "function test()", which is very intuitive. The newer language rust, where the command to define a function is "fn test()", is very concise, but I've never been negatively affected by its brevity; on the contrary, my code is cleaner because of it. I don't think we really need to give built-in functions well-understood names just because we can't understand what they do. Because it's a core function, we use it so often that we don't even need to mind whether we understand its name or not.
swagfag
Posts: 6222
Joined: 11 Jan 2017, 17:59

Re: Some beta eve preparations

02 Jun 2021, 00:16

  1. i think an autoformatter would rank closer to the nice-to-haves side than urgent on the spectrum. id argue a way more urgent thing to implement would be a parser or modifying AutoHotkey.exe with a command line switch to dump the AST of the passed in script. this would enable the development of things far more useful than an autoformatter such as code intel, LSP, linters and the like. moreover, since a parser is essentially a prerequisite for a good autoformatter, if one did exist, implementing the autoformatter would be a trivial matter. however, the converse is not true and currently no 3rd party(read: not Lexikos) dev is capable of creating a sophisticated enough parser for a language still subject to change, based on a spec that doesnt even exist
  2. ok, logistically how would that come to fruition? in AHK_H its rather straightforward: HotkeyIt implements the lib, according to HotkeyIt's standards and HotkeyIt maintains the lib. In AHK_L, these libraries are a mess:
    • some are Class-based
    • some are functions
    • some mix both
    • all have different conventions
    who is going to port them over and maintain them? Lexikos, like HotkeyIt does? i dont think he has a knack for implementing things he himself doesnt use(unless the benefits of doing so massively outweigh the costs, i guess).
    maybe we ask the authors of each respective lib then? some may not even wish to touch v2, but let assume some do get up to speed with v2 and port them. who is going to oversee the implementation? if its a standard library we're talking about, then i'd expect there be some, u know... standards, so i wont have to instantiate JSON classes; and call into GDIP functions; and use Arrays returned from calls; and have to double StrSplit by-ref outparam Strings that should have been Arrays to begin with; and have to check return error codes; or have to handle exceptions; or have to just blindly assume a call succeeded; etc, etc. what im getting at is, the interface and the implementation should be consistent and unified

    JSON is not compatible with AHK. there arent any boolean types, nor are there null types(unless u count unset as such, which i believe is incorrect to do so). it would be useful to have it in source, but i dont think its possible unless these 2 points are addressed first

    i dont know the exact backstory of LoadPicture but i have a suspicion it had already been implemented and was being used internally and was only exposed at someone's request once they noticed - so not quite similar
  3. i saw u making this VarSetStrCapacity() point several times now and to this day im still not sure what ure on about. how often do u use it? what for? i cant imagine someone having to use it all that often for its intended, documented purpose:
    Enlarges a variable's holding capacity or frees its memory. This is not normally needed, but may be used with DllCall or SendMessage or to optimize repeated concatenation.
    how often do u find urself having to explicitly free a variable's memory or enlarge a variable to optimize repeated concatenation? ive used it probably 3 times for the latter when dealing with some log files and not even once for the former reason... but maybe ure dealing with huge texts all the time, who knows...

    regardless, with v2's read-only auto-globals u can simply slap a vssc := VarSetStrCapacity(or whatever other name u find fitting) alias atop ur script and problem solved, no?
arcticir
Posts: 694
Joined: 17 Nov 2013, 11:32

Re: Some beta eve preparations

02 Jun 2021, 02:30

@swagfag

I don't know about everyone. I've been organizing my code manually, which wastes time, but I'm also used to it. However, after I used the excellent fmt tools for other languages, I became unbearable to maintain the neatness of my code manually anymore. I've even stopped writing new code and instead started thinking about how to implement ahkfmt.

I think we can all admit that std is very important (including Lexikos), so the question that remains is whether we have enough motivation to implement it. For example
1. create a new std partition in the forum and set up a std committee, the committee being the partition administrator. The admins review new libs and remove bad ones.
2. std-lib is not necessary to pursue uniformity. autoHotkey itself is very free, no matter what method is implemented, as long as the method is good enough, we can all accept it, right? Even for std-lib, users need to learn how to use it. When a novice needs to parse json data, he knows the lib has a json.ahk to use, he doesn't have to google "how to parse json with AutoHotkey", he just needs to learn how to use it based on the json.ahk information. This is the biggest point of std.
As an ahk veteran, std-lib doesn't matter to me, I can implement all the requirements myself. But when I look back at my experience as a newbie, if AutoHotkeye had std-lib, I would have taken a lot less trouble.

I've given up on any idea of function names. You can read it as a cleanliness obsessive-compulsive who can't stand the existence of any perceived stain (even if he will never touch it), especially for things he likes very much. Of course, as the documentation says, I'm using dllcall a lot. almost all my scripts are interacting with other DLL threads, other processes, other ahk processes.
swagfag
Posts: 6222
Joined: 11 Jan 2017, 17:59

Re: Some beta eve preparations

02 Jun 2021, 05:30

yeah, well, those excellent fmt tools for other languages have upwards of 300 contributors, a core team whose day jobs' is to maintain them and come up with the tools in the first place, and swathes of BigCorps backing them, whereas AutoHotkey has 2 active devs that work independently and do it as a hobby, some chump change in donations here and there(i presume, but maybe someone can post financials to prove me wrong) and a nonprofit pending administrative dissolution apparently lmao(@tank might wanna check that out).
so if an autoformatter is that critical of a component for u, better take advantage of the one that comes bundled with ur IDE, cause its not likely for ahkfmt to ever become a thing anytime soon
2. yeah, no, not really. thats exactly the point im arguing against. we've already conducted this experiment and it was a grandiose failure - look no further than v1, where half the shit is byref outparam commands that dont return anything; the other half - functions, some returning, some not, some throwing, some not, some having outparams themselves; and the rest of whats left - class based constructs. its a mess. v2 is by this point powerful enough to allow for the ports to be reimplemented in a uniform, consistent way. that way learning to work with one part of the standard library would grant u the transferable skills required to work with all other parts.
what's DllCall usage got to do with anything? i, too, almost exclusively use dllcalls, and yet the point stands - VarSetStrCapacity() ive legit used a grand total of 3 times since its introduction.
if ure using VarSetStrCapacity() as u would v1's VarSetCapacity() in dllcalls(ie not for the previously mentioned 2 other purposes), ure doing it wrong - use Buffer() instead
iseahound
Posts: 1582
Joined: 13 Aug 2016, 21:04
Contact:

Re: Some beta eve preparations

02 Jun 2021, 21:41

Most of AutoHotkey's stdlib is just DllCalls to the Windows API.
swagfag
Posts: 6222
Joined: 11 Jan 2017, 17:59

Re: Some beta eve preparations

03 Jun 2021, 15:07

:think: okaaayyyy.... still not sure what ure saying or why it should be considered relevant.
which AutoHotkey's stdlib? _L doesnt have one. do u mean the built-in functions/commands? what's DllCall got to do with anything? theyre implemented on top of the windows API but its just calls.
arcticir
Posts: 694
Joined: 17 Nov 2013, 11:32

Re: Some beta eve preparations

04 Jun 2021, 11:26

@swagfag
1. I feel hopeful to implement it, probably because I have experience in parsing "yaml|toml|json" and can learn a similar process to parse-reset AutoHotkey code. But I think I should wait for the Beta release before I start working on it, because the H version is slow to update now.
2. we need to focus on the focus of std - friendly to new users.
3. Buffer() is very beautiful.
swagfag
Posts: 6222
Joined: 11 Jan 2017, 17:59

Re: Some beta eve preparations

04 Jun 2021, 12:49

if u can do it, great. more power to ya. but lets not get ahead of ourselves, JSON and YAML have specs u could probably fit on a business card. AHK on the other hand, not only doesnt, but if it did have one, it would probably have been a behemoth rife with edge cases and ad-hoc additions(perhaps considerably less so for v2 in comparison, but still). im sure, ure well aware how similar past ventures ended up
User avatar
V2User
Posts: 219
Joined: 30 Apr 2021, 04:04

Re: Some beta eve preparations

05 Jun 2021, 03:01

@arcticir
A VSCode pluign can be used for code formatting:
https://marketplace.visualstudio.com/items?itemName=thqby.vscode-autohotkey2-lsp
20170201225639
Posts: 144
Joined: 01 Feb 2017, 22:57

Re: Some beta eve preparations

22 Oct 2021, 19:20

I just want a repl. Exploratory programming, posing random questions that can occur to me at any moment to a function and instantly see what it returns is for me the quickest way to build up a mental model of any function. It's the programming equivalent of "playing with" a physical thing, which is how the behavior of anything is usually learned. A shame I can't do that with AHK.

I've been thinking how one might be made. One issue is that AHK doesn't have dynamic variable creation, but I'm thinking my repl() can just fake it with properties of objects. If it reads "var1 := 123", it can just translate that to LocalVar.var1 := 123 locally.

As for function definitions inputted by users, well, I suppose most function definitions are expressions ultimately composed out of primitive values and/or calls to built-in functions. So it should be possible to handle those by Func.binds()? [1]

Is there any reason you *can't* build a repl for AHK or that any such repl is bound to be incomplete in some way?


[1] But I just remembered you can't call bind on BoundFuncs ...

Return to “AutoHotkey Development”

Who is online

Users browsing this forum: No registered users and 10 guests