OpenEuphoria

Re: For loops

• Posted by John E <jwfe at talk?1.com> Nov 19, 2007
• 624 views

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



Maybe there has been little response because FOR is OK as it is and
doesn't need changing ;)


> > 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.
> > 



Does this offer anything WHILE can't do?



> > 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


The changes proposed, IMHO, amount to a work-around for the absence of 
local variables.  Maybe add those?

If you want to go to the trouble, I suggest that adding a missing
control feature such as a do..while would be a more appreciated use
of your time.  This might prove to be simpler to do, too. (Only 
guessing there).


Regards,  John