Re: For loops
John E wrote:
>
> 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 ;)
>
If you read the forum for the past 7-8 days, you'll see that asimple bug report
about trace(1) triggered some activity indeed, and some requests for
additions/changes. The problem was that some of the changes were mutually
incompatible, so there was something to sort out.
>
> > > 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?
1/ avoiding to forget to increment counter at the end;
2/ protecting loop index from unwanted interference (by internally setting its
status to constant);
3/ protecting limit and increment, just like in a for loop, if they are
(subscripted) variables.
This is actually a variant of a for loop, rather than a while loop. Or a cross
breed between the two. The variant syntax "for with ..." was suggested instead of
"for_existing". It avoids a new keyword, but perhaps isn't as obvious for the
reader of the code. I certainly could live with it.
>
>
> > > 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"</font></i>
> > > 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
>
It is possible. But then what would be the difference with the modified for
loop?
The idea is that a for/for_existing loop uses a fixed increment to traverse some
fixed data structure or perform some operation. When it gets more dynamic than
that, use the while loop. That's my understanding at least. Currently, you must
use a while loop only beause you need some interaction with the counter. This
doesn't enhance code readability.
>
> The changes proposed, IMHO, amount to a work-around for the absence of
> local variables. Maybe add those?
If by "local" you mean with nested, coder defined scope like in C, then yes, the
issue could be handled this way. This is in Advanced Euphoria already (see
below), as a new scope ... end scope block, at the top of which you can define
variables (local or private) that go out of scope on reaching the end scope
statement.
There hasn't been much demand for this feature, so I didn't plan to introduce it
in standard Eu. But I'd consider it a good thing. Didn't you already see a flurry
of private vars most of which are used only in some branch of an if statement? Or
reused accidentally a var that should have been scoped out long ago?
>
> 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).
>
This was also suggested, but not much debated, as a do ... while loop is
strictly equivalent to:
while 1 do
-- something
if not <loop_again_condition> then exit end if
end while
Equivalent, but less verbose and making the intent clearer. I have it
implemented in my projet of modified interpreter - it may surface some day as
Advanced Euphoria, but is low priority at the moment.
The implementation of either is pretty simple actually, as it adapts the for
loop/while loop handling respectively. Scoped variables require adding an extra
field to the IL - and preventing ? to display an out of scope for loop var when
tracing could require it as well. This is a little harder, but can be done.
CChris
>
> Regards, John
|
Not Categorized, Please Help
|
|
