OpenEuphoria

Re: trace(1) bug

• Posted by CChris <christian.cuvier at ?griculture.gou?.fr> Nov 14, 2007
• 549 views

Pete Lomax wrote:
> 
> CChris wrote:
> > 
> > Pete Lomax wrote:
> > >}}}
<eucode>
> > >procedure x()
> > >integer i
> > >    for i=1 to 10 do
> > >    end for
> > >    for i=1 to 20 do
> > >    end for
> > ></eucode>
{{{

> 
> > If there are both an integer i and a loop index i, the later shadows the
> > former
> 
> In the case given, I meant they should be one and the *same*.
> 
> Correct, this would constitute a change to the language spec.
> 
> I trust you agree that allowing the above construct cannot break any legacy
> code. Can you think of any reason, or example, why all 3 [local] i above refer
> to same var would cause a problem?
> 
> Regards,
> Pete
> 
> PS there may be cases where a predeclared "integer i" must instead be "atom
> i" to marry with subsequent f.p. loops, I hope such can be handled ok.

Technically, it is not a problem. If you remember OpenEu (lowercase), you may
remember a wfor loop proposal too. Yours resurrects it. It is useful to have, at
least convenient.

But imho under another name than "for",  be it "wfor" or something else. I'd
probably prefer something else actually - "iterate" perhaps?

The difference between a for loop and a wfor loop would only be that a wfor loop
doesn't define a scope, so that its index has to exist prior and remains in
existence beyond its end statement. It is a specialised while loop actually,
which motivates its historical name. In contrast, the current for loop would
remain a scope by itself, with no reason for its index to be valid outside it, as
it is now. Both are useful, so let's have the two constructs.

Currently, a for loop index should not exist prior ("attempt to redefine i"); I
don't see any problem in changing this so that the loop index shadows anything
with the same name as long as it is alive, except another for loop index. It
won't break any code. I don't see why defining a top level integer i after having
top level loop indexes named i should error out - it shouldn't, since the loop
indexes are out of scope by then, so i is not being redefined.

And since for loop indexes don't exist after the loop is exited, I'd suggest
simply removing their display from ex.err (or set them to NOVALUE on exit),
solving the second problem shown by my original code (loop index displayed past
its bounding end statement). The first one (wrong loop index displayed by ?) is
easy to fix without changing anything in the language.

Opinions?

CChris