@DarkDragon : In looking for ZScript parser bugs to fix, I would consider this scope bug to have a rather high priority, as no-one was ever able to resolve it:

Code:
ffc script foo{
    void run(){
        int x = 10; int w; 
        for ( int q = 0; q < x; q++ ) {
                if ( q % 5 == 0 ) {
                    int y = q * 2;
                    w += y -q;
                }
         }
    }
}
The issue, is that using this example...

1. The value' q', declared in the for loop, uses stack space, perpetually. It is only available to the scope of that for loop, and the if statement, but it always uses a register. This particular issue has ruined the day of many scripters, who declare for loops in scripts, and expect variables to only be in use when their scope is active. Repeated declarations of a loop condition, particularly in for loops, will cause stack overflows.

2. Likewise, the variable 'y' is only available to the scope of one if statement, and yet, it also eats up stack space at all times. Essentially, any variable declared inside the scope of a function, even at a lower scope such as a statement, is not released until the function exits.

3. Because run() is a function, and it never exits, variables inside these scopes in scripts eat up stack space at all times.

Clearly, variables at the run() scope need to remain in use, but variables declared at lower scopes should pop off the stack when their scope exits; yet they do not at present behave in the expected manner. This is an easy way to confuse scripters when the stack overflows from no apparent cause, because they expect variables to pop off that never do.

I don't know if you can give this any attention, but it is one of the more serious flaws in the parser.

At present, most of us just try to train users to declare arrays at the scope of run() and never declare loop operators at a scope lower than run(). THis is a very bad system for handling an issue of this sort, as you can likely imagine. Any ideas on how to resolve this one?