Re: trace(1) bug
- Posted by Andy Drummond <andy at ?estreltele.co?> Nov 15, 2007
- 576 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