I have two beefs with the way script arguments are handled in GML: it's a pain in the ass to declare a lot of them, and you can't be sure whether a particular parameter was omitted or not. Here are my suggestions for addressing these problems:

1. Script Parameters
In addition to the current argument# and argument[] variables, I suggest a new keyword, "param". This declaration would declare the variables that follow it as local variables, as with the "var" statement, and would also assign arguments to the variables.

Example:
param x1, y1, x2, y2, color;

...would have the same effect as the following GML code:
var x1, y1, x2, y2, color;
x1 = argument0;
y1 = argument1;
x2 = argument2;
y2 = argument3;
color = argument4;

This new syntax would improve readability, require less typing, be less error-prone, and also make it easier for automated tools (such as the GEX builder) to determine which parameters a script is expecting.

This change would be backward compatible with existing GML code.


2. A "None" value
In the current GML implementation, the value of an argument which was not passed to the script defaults to zero. This is an unfortunate choice, since zero is one of the most commonly-passed values. There is no way for a script to know whether the calling code omitted that parameter, or explicity passed a zero value.

I suggest that a new "none" constant be added to the GML language. This could perhaps be implemented within the standard 64-bit data type by using one of the bit combinations that does not map to a valid double-precision number, or as a third data type, in addition to real and string. Arguments which are omitted in the calling code would be assigned the "none" value within the script.

The only valid comparison for the "none" value would be ==. Assigning "none" to a variable would be valid. Performing arithmetic on it would be an error. The is_real and is_string functions would both return false if passed "none".

This change would not be backward compatible with existing GML code. A global game option could be added to "treat omitted arguments as zero", which would restore compatibility.

2a. An "argument_num" variable
If the "none" value is too complex to implement, the same problem could be solved by creating a built-in "argument_num" variable, which would hold the number of arguments passed to the script. This number could be checked, allowing the script to know which arguments, if any, were omitted. Although a "none" value could be handy in certain other situations, this solution is probably much simpler to implement, and is backward compatible with existing GML code.

In standard programming jargon, I think the "none" variable is actually called "null", so if suggestion 2 is implemented, it should be called null rather than none..