I've never considered the existence of a map() function to be paramount, but rather trivial. In other words, I was surprised that a map() function was not built in.
Had a map() function been built in, it would have error-ed out because:
- Click is not a function, so map would have returned an empty state.
- The fact is that an object can not be the 1st argument due to partial evaluation and binding of arguments, currying
Currying evaluates a function by taking a function with multiple arguments and evaluating its first argument first, thus returning a function that accepts a second argument. I've shown how this would be accomplished in AutoHotkey, and honestly it's slightly weird with percent signs around the function reference. The truth is that many people would consider the order of arguments to be insignificant, but that's because AHK makes things easy. It can seem insignificant, but when designing a computer language, it's important to realize that it's a system for computation. And computation is a form of change, which most math teachers would call calculus. So looking back towards lambda calculus, we can see that multiple arguments do not exist and only the concept of partial evaluation or decomposing an input into multiple arguments exist. It happens that both forms are isomorphic, so choose which ever form is more convenient.
As for it seeming unnatural for Click
to return its arguments, the only explanation that remains is that click is not a function but an effect. Any attempt to return a window, or something else is too non-deterministic, and likely to error out. It may be possible, but for the time being it should return nothing since it interacts with the world, and a program in AutoHotkey, like most programs, make assumptions about the world. (in fact most languages like Python which output to the console make 0 assumptions about the console, or even if the console exists. I think that if stdout isn't captured it just disappears or gets garbage collected or something.)