Re: For loops
CChris wrote:
>
> 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
For those who have followed my meanderings it will no surprise if I accept
this proposal. I just wondered why it would not be possible to write the
for_existing iterator within the loop. This agrees with current for-next loop
coding, but I don't see why it needs be preserved. Otherwise, I concur with
CChris's proposition.
AndyD
|
Not Categorized, Please Help
|
|
