Hi,
(Ok, this will be confusing).
The main reason Goto is not supported in Strict mode is that it can cause highly irregular code paths that can confuse the compiler and prevent a bunch of optimizations.
For example:
Goto there
Local tmp=100
#There
Print tmp
...means that 'tmp' must be initialized prior to the Goto or you'll get a nonsense result. Which means that locals can not necessarily be initialized where they appear in the code. Which, combined with the fact that Goto can jump in and out of scopes, complicates the compiler immensely.
The solution for non-Strict mode is simply to move all Locals up to the 'top scope'. But this can severly limit optimization, eg:
If x<y
Local t=10
...blah...
Else
Local q=20
...blah...
EndIf
In non-strict mode, both t and q are 'moved up' to the top level, and the code to 'null them out' is always executed - even though only one of them is ever used.
However, in strict mode, the locals are only initialized if their codepath is taken - eg: if x<y, then q is never initialized and vice versa.
Yes, it is possible for code analysis to deal with these issues (or at least, detect them), but it's complex and I didn't think worth the time. C++ does this, but it can generate some bizarre related error messages, like 'initialization of blah skipped by whatever'.
And yes, Strict mode code should be slightly more efficient!
I haven't used Goto for many, many years now and have got by fine. Although thinking about it now, I suspect I tend to 'functionize' blocks if they get too deep and I need an early out.
I don't like either 'Exit 2', 'Exit For', 'Exit For, While' or whatever. All these solutions mean that changing or adding enclosing blocks is potentially dangerous.
Instead, I would tend to go with Java's solution, which allows you to 'label' a block and then use Exit with that label, eg:
#MainLoop 'In strict mode, must be followed by an 'exitable' statement
While blah
Exit MainLoop
Wend
This is definitely doable.
(Ok, this will be confusing).
The main reason Goto is not supported in Strict mode is that it can cause highly irregular code paths that can confuse the compiler and prevent a bunch of optimizations.
For example:
Goto there
Local tmp=100
#There
Print tmp
...means that 'tmp' must be initialized prior to the Goto or you'll get a nonsense result. Which means that locals can not necessarily be initialized where they appear in the code. Which, combined with the fact that Goto can jump in and out of scopes, complicates the compiler immensely.
The solution for non-Strict mode is simply to move all Locals up to the 'top scope'. But this can severly limit optimization, eg:
If x<y
Local t=10
...blah...
Else
Local q=20
...blah...
EndIf
In non-strict mode, both t and q are 'moved up' to the top level, and the code to 'null them out' is always executed - even though only one of them is ever used.
However, in strict mode, the locals are only initialized if their codepath is taken - eg: if x<y, then q is never initialized and vice versa.
Yes, it is possible for code analysis to deal with these issues (or at least, detect them), but it's complex and I didn't think worth the time. C++ does this, but it can generate some bizarre related error messages, like 'initialization of blah skipped by whatever'.
And yes, Strict mode code should be slightly more efficient!
I haven't used Goto for many, many years now and have got by fine. Although thinking about it now, I suspect I tend to 'functionize' blocks if they get too deep and I need an early out.
I don't like either 'Exit 2', 'Exit For', 'Exit For, While' or whatever. All these solutions mean that changing or adding enclosing blocks is potentially dangerous.
Instead, I would tend to go with Java's solution, which allows you to 'label' a block and then use Exit with that label, eg:
#MainLoop 'In strict mode, must be followed by an 'exitable' statement
While blah
Exit MainLoop
Wend
This is definitely doable.