OpenEuphoria

Re: For loops

• Posted by CChris <christian.cuvier at agricultur?.gouv?fr> Nov 20, 2007
• 591 views

Matt Lewis wrote:
> 
> Andy Drummond wrote:
> > 
> > c.k.lester wrote:
> > > 
> > > Would this be too far outside Euphoric philosophy:
> > > }}}
<eucode>
> > > for( x, x+1, x < 10)
> > > -- ...
> > > end for
> > > </eucode>
{{{

> > 
> > Yes. way too far!  I would prefer that what we have now continues to work.
> > I feel, having thought a bit, that CChris's idea to allow the scope of the
> > for loop iterator to persist beyond the loop as a constant is pretty good.
> > It allows the programmer access to the value of the iterator when the loop
> > decided to terminate (not always when the limit is reached) without doing
> > any harm to existing code.
> 
> But that's just one way to do it.  What about, say:
> }}}
<eucode>
> object in
> loop in = gets(fn) while sequence(in) by in = gets(fn) do
>     -- ...
> end loop
> </eucode>
{{{

> We've got the same elements (initialization, condition for continuing and
> command for iteration) repackaged in a more euphorian manner.  A simple 
> alternative would be:
> }}}
<eucode>
> object in
> loop in = gets(fn) until atom(in) by in = gets(fn) do
>     -- ...
> end loop
> </eucode>
{{{

> This is perhaps clearer, since it doesn't overload the while keyword, and
> is probably more similar to the current for-loop construct.  Maybe both
> could be supported, though the use of 'not' in the condition would be
> equivalent.
> 
> And maybe any and all of these 'subclauses' are optional, so that all of
> the following are valid (even if possibly nonsensical examples):
> }}}
<eucode>
> loop until atom(in) by in = gets(fn) do
> loop in = gets(fn) by in = gets(fn) do
> loop by in = gets(fn) do
> loop do
> </eucode>
{{{

> 
> I don't think that any of these enhancements would require a change to
> the back end at all, since we're just putting things together differently.
> The IL code would probably map to a WHILE opcode, with different jump
> points set to inject the extra iteration code.
> 
> > I also feel the continue statement would be valuable but I have never liked
> > 
> > the choice of word. Would "next" be better? Implying that the next loop is
> > to
> > commence immediately?
> 
> I'm fine with either one.  I think that this is a very worthy proposal (ooeu
> already has 'continue').
> 
> Matt

AE maps the

do [label "some string"] ... until <exit_condition>

construct to

while 1 do [label "some string"]
...
if <exit_condition> then exit end if
end while

and indeed doesn't require anything new in the backend. 
Neither "next" (aka continue) nor "retry" (repeat current iteration, skipping
any increment or test), also in AE, do.

next and retry, as well as exit and exif, support an optional parameter:
* relative # extra levels to exit
* -# number of loop to exit (-1 = exit topmost and so on)
* a for loop variable (exif doesn't support this)
* a label, which is a double quoted string referenced by a "label" clause.

The various branch targets are resolved in the parser, which handles delayed
jumps by scanning a sequence at each block exit and backpatching when the branch
is ripe. The backend doesn't see anything new, as the EXIT opcode is being
emitted.

Of course the optional param could be restricted to be only a label. In the
simplest cases, this is probably overkill, but is theoretically true and safer,
as CB already emphasized. The resulting code simplification would be  marginal,
since a single routine handles the optional parameter in the parser.

Everything works as expected AFAICT.

I didn't implement the "by" clause of the do loop because it is enough to put
its contents at the end of the loop body, so it seemed redundant. Unless there's
a refined semantic hue I didn't get.

Only possible issue: variables named "label", "until", "next", "retry" or "exif"
will need a rename. "label" is allowed only right after a do/then header end
marker. And a so much steeeeeeeeeeper learning curve, I'm sure.

CChris