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:
The only thing I think might be added to for is continue.
As far as the the other things that you are talking about
are just not necessary because they all can be handled
simply by using the while loop.
I think you are concentrating to much on change and complicated
features.
Just add simple features that do not break code.
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
|
Not Categorized, Please Help
|
|
