Darkstar Wrote:This works:

Code:

For i = AttrAddress to AttrAddress + NumberOfCells - 1
  Poke i, AttrColor
Next i

This does not:

Code:

For AttrAddress = AttrAddress to AttrAddress + NumberOfCells - 1
  Poke AttrAddress, AttrColor
Next AttrAddress

This would work in other dialects.

Thanks,

Darkstar

britlion Wrote:Boriel,

I think that's probably the right choice, since most basic dialects use it. You can always do a dynamic expression with a do...until (x) style loop, where it feels more natural to have an expression evaluated each loop, I think.

Will static evaluation speed up for loops?

boriel Wrote:At the moment, the only way to fix this is:

Code:

LET z = i + N - 1
For i = i to z
  Poke i, AttrColor
Next i

Can you check this?

Which produces the expected behavior. I'm thinking in fixing this in an more efficient manner, so the user can choose dynamic or static FOR loops with a #pragma directive, and let FOR to be static by default for compatibility's sake. What do you think?

boriel Wrote:I also agree with both Britlion and you. I'm going to implement this behaviour by default. If the programmer wants the dynamic behaviour s/he will be able to enable it using something like:

Code:

#pragma for dynamic

or

Code:

#pragma for static

which will be enabled by default (needs not to be used unless you want to switch from/to dynamic for). What do you think?

boriel Wrote: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.

Darkstar Wrote:

boriel Wrote: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)

boriel Wrote:

Darkstar Wrote:

boriel Wrote: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.

Darkstar Wrote: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...

boriel Wrote: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.

boriel Wrote:Notice also that FOR upper limit is evaluated ON EACH iteration (like C). So if len(a$) changes, the loop will shorten. So better use a temporary var l to store initial LEN(a$).

Arrays subscripts starts from 0 to N-1 (like in C). But this behavior can be changed using --sinclair or --array-base switch.

NOTE: I'm planning (for compatibility) an --string-base (so LEN and string-slicing will work exactly as in Sinclair BASIC, by specifying --string-base=1). Also with FOR, stating --constant-for etc...