mSL is the only language I know of that has such a cross-play between two unrelated data stores; as an analogy, it's similar to if /tokenize altered an unrelated hashtable.
I know quite a few languages that support this, sh/bash scripting being the most obvious (and seemingly the influence behind the $1- design):
# run as: ./foo arg1 arg2 arg3
# outputs:
# arg1
# bar
#!/bin/sh
echo $1
set -- bar
echo $1
Perl allows for rewriting @_, which also represents the initial arguments. There is no specific command to do so, but it exposes the same functionality. That said, Perl
does allow overwriting of arguments in another way with $_. For example, most functions operate by default on the $_ string, which may contain data from the last call. @_ and $_, just like $1- in mIRC, are just stores for data, nothing more.
Basically, $1- is simply the resulting store for the last call to /tokenize, with the assumption that mIRC calls /tokenize (internally) for you to seed the initial parameters. It's effectively a "register" based design. This seems completely consistent with all other register based designs in mIRC-- for example, $regex() fills $regml() of the last call, and future calls will override this value.
You're calling /tokenize and $1- unrelated (like an "unrelated hash table"), but they are entirely related by design. In fact, the very purpose for exposing /tokenize was specifically to allow scripts to re-write the argument list. I think you might be using /tokenize for an unintended purpose, i.e., to avoid $gettok() and effectively (mis)use $1- as a low-cost "array" syntax. It's certainly an interesting use of $1-, but it doesn't seem like the intended use.
It seems to me that what you really want is array support in mIRC, period. That way you're not needing to use /tokenize at all.
That is something I think a lot of people (including me) can support, especially since it's much more generalized and useful for other non-argument-list cases too. But it shouldn't be exposed through /tokenize or $1-, it should be its own thing. Otherwise, you're effectively limiting array syntax to scripts only being able to operate on a single list at a time.
As a sidenote, the loop in your JSON example would actually probably be faster with $ [ $+ [ %n ] ] than $args(N), specifically:
%call = $+(%call, $chr(91), $qt($ [ $+ [ %n ] ] ), $chr(93))
Or, rather, put in another way, based on the benchmark I posted above, it's unclear that $args(N) would be useful in the above case-- it may end up still being slower, which means nobody would use it for this use case (since it's no more convenient either). This is relevant, because if array syntax does come, it should come as a
core syntax, not an identifier (like hash tables), otherwise it too may end up being slower than bracket evaluation at the end of the day (due to the way parsing and function dispatch works in mIRC). Then again, if mIRC's parser / dispatch was ever to be optimized, that problem could be solved and it wouldn't need to be a syntax instead of an identifier (incidentally, using hash tables for a list would probably become faster than bracket-eval too, and maybe an array syntax would not even be necessary).
