Yellow, GM is pretty much typeless, so you don't really need to put a type to the variables. (It isn't really typeless, but it's masked for beginners).
Here's an idea, to make it possibly easier for beginners...make it a new tree item (like sprites/sounds/fonts/objects, etc.)...."structures". When you create a new structure, the same code editor for scripts is used, but a slightly different convention.
The reason I suggest it this way is because 'scripts' and object code are run as the interpreter reaches them, which means those structures will not be known until it gets run (and then possibly be redefined EVERY time it runs). Having it separate from the codebase itself will allow it to be defined at compile-time instead (although the "compiler" could look for these things in scripts/code and make them global, but that can confuse beginners as it is).
I prefer the following myself:
//"stats" structure
var experience, nextexp, level;
experience = 0;
nextexp = 100;
level = 1;
proc gain
{
experience += argument0;
if(experience >= nextexp)
{
level++;
nextexp *= 2;
}
}Since GM uses 'argument#' for args in scripts, there is no need to worry about adding more complications to the mix (but if you decide to add the ability of naming args, so be it). What I see the above doing is simply defining 3 variables within the structure and a procedure, which would allow this:
PlayerStat = structure_create(stats);
PlayerStat.gain(120); //yay, level up!
Technicals:
During parsing of structures (which should be relatively first), save the code position of the bytecode table to the name table for the structure and any 'vars' are noted within the structure and stored in the name table as well. If 'proc' is parsed, push code table, compile the definition and store the code within the name table for the procedure (using "this" as target for the variables inside which are also found in the name table for the structure), pop the code table back. Any other code found will be considered "initializer" code, simply target 'this' for any variables defined within it and when finished parsing, out a return bytecode.
After that, run through the name table for all procs, store the current code table position in the name table for the proc and push the code to that position. During the parsing of the rest of the application, struct_new() for it will call the initializer bytecode (stored in the name table at the beginning), any time a procedure is identified, call that position in the bytecode (also now stored in the table).
This would require your original 'collection' idea, where variables will be flagged for what it contains.
edit: oh, yeah, forgot. When calling the methods, 'push' the 'this' variable and make 'this' target the structure....and afterward 'pop' it back. That should have been obvious for compiler makers, but I forgot to mention in technicals.
Edited by sabriath, 06 February 2011 - 02:34 PM.
This topic is locked
