Note that this is not a normal GM function. I mean if this were a normal function,
would try to read the value from the variable myarray and then execute the function on its value. However what is meant is using the name myarray. Actually, it is more like
Ism was merely using the same parameter format forwarded by Mike with dim(i,20). It's clear that either he intends to change that behavior to accept references (which would be rather interesting), or he was speaking in a less literal sense.
I'd like to second the notion of array_init; Dim() breaks a long-standing convention, most people don't live long enough to type variable_local_array_set every time they want something done, and `dim' shadows a BASIC instruction.
That said, I'm also with Rusky on the proposal to allow i = [1, 2, 3], or for that matter, shamelessly steal from MATLAB and allow i = [1..20], or, though I can't imagine it, i[0..20] = 0. I'm not fond of the latter proposal, but i = array(20,0) would be fine. The first issue I believe you'll run into is that GM doesn't have default parameters, so the 0 must be explicit or the system must be modified. It also doesn't allow setting arrays... perhaps you could consider defining a new operator for array copy. Really, I'm just throwing out some ideas.
As for your script parameters, what I have done is this:
1) Move argument0 and co. into the script scope, as you seem to have already taken for granted,
2) Allow an unlimited number of parameters (any reference to argument# will be accounted for),
3) Default all used arguments to zero (so if they are passed, only necessary copying is done, while if they are not, no unused variables are set).
That introduces one vulnerability, namely, if you use only argument0 and argument256, you will end up with 256 parameters of useless slag. Considering how queer a scenario that is, I choose to ignore it completely and assume no one will ever notice.