OpenEuphoria

For loops

• Posted by CChris <christian.cuvier at ?gr?culture.gouv.fr> Nov 18, 2007
• 654 views

Since there hasn't been much activity on this after some ideas wwere tossed,
here would be my proposal for changes/extensions:

1/ Change to the for loop semantics

Here would be the new rules:
* The loop index of a for loop will be available as a constant after the loop
ends, until it is redefined by another for loop or declared as a regular
variable. This is a change.
* The loop index, if private, can have the same name as any non private symbol,
and stops shadowing it on leaving the routine it is defined in. No change here.
* The loop index cannot have the same name as a previously declared variable in
the same routine (all top level code lumped together counts for a routine). No
change here.
* The loop index may have the same name as another loop index in the same
routine if that other index is not active at the time of its definition. You can
thus have two loops with same index following each other, but bot nested in each
other. No change here.

2/ New construct

for_existing <index>=<start> to <end> [by <increment>] do
-- something
end for_existing

The loop index must be a variable currently in scope and able to be assigned an
atom. That variable will not be accessible for write inside the loop, even from a
routine called from the loop.
If the limit or optional increment are variables, they may be modified inside
the loop, but the changes won't affect the limit and increment of the loop.
There are no other rules concerning its name, since it is an existing variable. 
On exiting the loop, its index variable becomes accessible for write again.
Incrementing the loop variable will not cause a type check.

So this would be like a for loop, but using an existing variable.

3/ Change in ex.err dumps

If a variable is defined several times in a scope, like for loop indexes, only
the one defined last at the time of the dump will be displayed. This is a change.


Expected code breakage: 
* none for 1/, since the change in 1/ will make legal code that currently isn't.
* some (or perhaps none) with 2/: programs which define variable(s) named
"for_existing" will require this name be changed.
* none for 3/, since code isn't involved.
No performance hit is expected.


Any comments?
Since I expect to move this week, the changes, if agreed upon, won't be
committed before next month.

CChris