OpenEuphoria

Re: trace(1) bug

• Posted by Andy Drummond <andy at ?estreltele.co?> Nov 15, 2007
• 577 views

c.k.lester wrote:
> 
> Andy Drummond wrote:
> > c.k.lester wrote:
> > > Andy Drummond wrote:
> > > > My personal preference - if worth anything - is that if a variable
> > > > has been declared when used in a for loop, then that variable is used.
> > > > Then it is in scope after the loop exits.  If no such variable has
> > > > been declared then it is a local to the loop and out of scope as soon
> > > > as the loop exits.  This seems entirely consistent with the normal 
> > > > practise of variable scoping when functions are defined....
> > > Please, no. I want this to be a goof:
> > > integer i
> > >   i = find(x,y) -- i is now 32
> > >   for j = 1 to 10 do
> > >     for k = 1 to 10 do
> > >       for i = 1 to 10 do -- DO NOT ALLOW
> > >          ...
> > >       end for
> > >     end for
> > >   end for
> > >   ?i -- better be 32
> > Why do you want this to goof?
> 
> Because it's a mistake. In this case, I did not intend to overwrite the
> 'i' variable; I did it on accident.
> 
> > So why you expect the i to remain 32 after changing it in a for-loop? If you
> > had wanted the for-loop iterator to be different then call it something
> > different.
> 
> Right now the interpreter protects programmers from making this mistake. If
> you want to be able to use an already-declared variable in a for loop, make
> a new way to iterate. Don't mess with for...end for!

What you say is true, of course. It just seems odd that a variable created
within and scoped only to a for-next loop precludes that variable being what
is effectively a non-local variable. It's as if using a local variable x
stopped you having a global variable x - of course it doesn't; you use the
global x or a local x. If you use the global x and change it then the global
x changes!

It is nice that Euphoria allows you to define for-loop iterators in the
loop definition itself.  But that means that if I use i for example in the
loop I am forbidden to have i within the rest of the routine with the loop in.
This means I have one - or more - variables I cannot use within the body of
the routine because they are used in for-loops *even though* I can't access
them within the body of the routine. That seems inconsistent. If I want to
know the iterator value after the exit I have to have another variable to
load it into for that purpose.

I will accept what you say - that if people code wrong they will get wrong
results. But why force procedures that complicate matters - and require more
variables - just so that people can use already defined variables a second
time without fouling up the earlier usage. Surely it isn't too much to expect
programmers to use different variables for different values?

Apart from all that, a change as I suggest - recommend - would not break
existing code because it wouldn't have passed the syntax checking thus far.
But OK, if you must have it this - IMNSHO - inconsistent fashion, so be it.
Euphoria is still a darned good language. If you want it to stay as it is, OK.
If you want improvments then something is gonna have to change...

AndyD