A For-Next bug in 1.2.8-s682

[Darkstar]

Implementing dynamic is much easier (it's already done) and saves memory comparing to static. Static might be faster sometimes (eg. when using expressions), and take twice the memory for each iterator variable. I think leaving it alone should be ok (since almost no one will be using it). FOR is currently "dynamic" and has not caused much trouble when porting original Sinclair BASIC programs.

In fact FOR loops are expensive in much ways (code, speed, etc). While and DO...LOOP are much faster and simpler.

If you use expressions then you already have to use an extra variable (double the amount)

Not exactly: the code that computes the FOR upper limit expression is the same (regardless its static or dynamic calculated on each iteration). The difference is that once it's used it's discarded (dynamic) or must be stored to be reused later (static). Other than that, there's no difference. I was to implement that anyway (there's another thread in this forum asking for that), but leaving the possibility to use a dynamic for if one wants. I meant: can't see why we must enforce dynamic removal once static is the default behaviour.

Yes, it throws it away and if you want to retain it then you have to set
up an extra variable in your code and by logic I assume that if you use
the upper limit as an iterator it overwrites the upper limit instead of
the case with static where it is kept as a single background variable.

No need to enforce a removal but I do not see much sense in keeping a
dynamic structure unless you want to shave off a one extra internal variable
and the code to manage it meaning certain limitations. If you want to be
really smart then the compiler could decide which loops would benefit
from a dynamic structure vs a static one, and instead of having two sets
of For-Next code in the compiler just do a branch based on a flag but that
could eat up the savings made so...

If you were going to implement it anyway then that's good, as a default.

Thanks,

Darkstar.