[wish] Named parameter/argument operator symbol

[SandyClams]

so I noticed as of a134 that named parameters are on the table. This got me thinking about a few different things....

first, lemme just introduce the idea of flag parameters. The purpose of flag parameters would be to serve as constants in supplying arguments to a function call. The use case would be, anywhere you're trying to call an AHK wrapper function around a Dll/WinApi call, or a Send/Receive message, which itself natively takes flag style arguments, that wrapper function could instead be supplied "flag" arguments, i.e. constants that are local to the call expression, which are then recognized and handled inside the wrapper. The intended goal is, hopefully, to greatly increase the flexibility and ease the pain of calling these kinds of wrapper functions in the currently available ways: string key arguments, craploads of positional arguments, semantically meaningless numeric arguments, etc.; surely it's possible, but it's definitely not optimal. It's also possible, of course, to attain to this same general functionality by manually defining a bunch of constants (variables) in the global namespace, but one, who the heck wants to do that, two, they'd have to be very unique and thus painful to use in order to even coexist with one another, and three, you'd still have to work around variable scoping issues, and it's definitely not optimal. So, considering these things, my thinking is converging on something like these "flag" parameters.

so I continue with this, and I ask, well, how would they work? Ideally, in as much as it is possible, they would be supplied as bare identifiers to the function call, as though they were existing variables. I'm assuming this would be highly problematic though, probably for AHKs preprocessing itself on script load, but at runtime and for code analysis tools at the very least -- the reason being that each function call would need to have its definition preemptively referenced just to determine how to interpret its supplied argument values, and specifically whether to interpret them as undefined variables, i.e. as errors. Even if the flag arguments were only first encountered at runtime, it would still be extremely inefficient to have their resolution dependent on checking some auxiliary thing, that being the unique rules of the function definition. I don't know the implementation particulars but I can't imagine that doing it this way could ever be possible; I assume it would have unacceptable implications to the fundamental way AHK runtime evaluates values.

anyway, one thing that definitely could address some of these same needs as flag parameters would be named parameters. That is: if a certain named argument is present, handle it inside the wrapper function as though a known flag was given, ta daaaa, lots of needless issues with the function call are now much more comfortable. Though, for reasons of aesthetics and reducing redundancy overall, I think to myself, it would be far superior if the values of those named arguments were allowed to be empty, and if the arguments could simply be names. Consider fn.Call(FLAG1, FLAG2) vs. fn.Call(FLAG1 := 0, FLAG2 := 0) when in both cases the only matter of relevance is whether the name is specified at all, not the values of the arguments. I mean, if we're gonna type out assignments for each argument name, we might as well just use object arguments and handle the object's member names as named parameters. Empty named arguments, I feel, would be waaaay better.

of course, then we're back to the issue of how the named argument is distinguished from an unset variable at runtime without unnecessarily referencing the ruleset of the function being called. So it's around this point that I figure: we need an operator, an operator for named parameter arguments to signify they are named, so that they can also signify that they should be handled differently than other identifiers. Why? So that they can be empty, so that they can be flags. Actually, looking at my little example above, it would seem necessary one way or the other that named arguments be distinguished by some unique syntactic element of some kind, even just to supply them at all and differentiate them from assignment expressions (or from whatever other expressions they could conceivably look like I guess). So, preliminarily, I say an operator symbol, but if some other syntactic element is better, then hey, cool beans.

but ya, @lexikos, I know you do whatever you want, and I'm not under the impression named parameters are necessarily even coming, I just wanted to put forward some of these ideas for your consideration before you potentially started going somewhere with them, so you would have them.

@ anybody else, curious if you have any thoughts about the usefulness of flag style arguments in AHK re: working around DllCall/WinApi/messaging, have any better ideas, etc.

[SandyClams]

addendum, something I also consider but forgot to mention alongside the main concept: if you really wanted to go balls-out, you could even ditch the named parameters totally and instead have something more like named parameter expressions, with the traditional named parameters themselves just being a subtype of "named parameter expression" -- that is, an assignment expression subtype -- which proceeds to be evaluated inside the scope of the function that is supplied the named expression as an argument. This would allow for something crazy like fn.Call(@fn2(val)) as well as the already established fn.Call(@argName := val). Granted I'm not sure offhand what I would do with something like this, but it would sure be powerful, and interesting. **Edit: I remembered why my thinking approached this idea. It's so that, when using named arguments as though they are flag constants, the arguments can also include, say, bitwise operations between multiple flag values, etc., without requiring the aforementioned needless referencing of the function definition to determine how the operations would be performed.

addendum 2: on the other hand, say the operator wasn't a named parameter operator at all, but a lazy evaluation operator. In that case named/expression parameters could conceivably be implemented merely by supplying a "lazy evaluation object" (or whatever) as an argument to a function that was equipped to handle it.... or maybe to any function at all, if the expression were made to eval itself automatically on being passed? Definitely haven't thought these things through very much, just playing with the ideas really