Re: trace(1) bug

new topic     » goto parent     » topic index » view thread      » older message » newer message

Pete Lomax wrote:
> c.k.lester wrote:
> > 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
> 
> By the same token should the compiler complain about:
> }}}
<eucode>
> integer i
>    i = find(x,y) -- i is now 32
>    for j = 1 to 10 do
>      for k = 1 to 10 do
>        i=11
>      end for
>    end for
>    ?i -- better be 32
> </eucode>
{{{

> 
> If not, why one and not the other?

Why should it complain in the case you present? i has been declared and
initialized and can now be set at will in the context of the space in
which it was defined. There is no mistake in assigning it a value, and
this would be easy to debug.

> In my book both mistakes are equally easily made, found and fixed.

It might not be easily found in the case I presented, especially if the
declaration and assignment were two screens separate from the errant for
loop.

I admit I'm wanting to protect the coder here from making a mistake that
might be hard to debug. I don't disagree with the construct being suggested
where a variable can be reused in a for loop... I just don't want the
current for...end for behavior changed.

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu