local and do <commands> - what NOT to do

[-hh]

Kay C. L. wrote:
> Moving right along, for those Slack Moders, if you run the same statements:
> 
> repeat with x=1 to 20
>   do "local tVar_" & x
>   do "put x*x into tVar_" & x
> end repeat
> put tVar_5 into msg  --not hidden in <do>
> 
> For reasons I do NOT understand, you get a runtime error:
> 
> line: do "local tVar_" & x
> hint: local tVar_5
> 
> If you remove/comment the line: do "local tVar_" & x
> 
> everything will then run fine - reinforcing your decision to choose Slack
> Mode because declaring vars is so 3GL ;-)
> 
> So long story short; contrary to the example, it would seem to be
> counter-productive to use <local> within a <do> statement.


Hi,

I read about "do" again last night, because Craig N. (in a comment to
Peter H.'s QCC #16941) suggested to use single quotes also for triggering a
re-compilation, as "do" does.
He used a 'declaration'-example similar to yours.

Now you end in a rather nifty example.

on mouseUp
  repeat with x=1 to 20
    do "local tVar_" & x
    do "put x*x into tVar_" & x
  end repeat
  put tVar_5 into fld 2
end mouseUp

[1] In strict compilation mode it throws "unquoted literal" on "tVar_5", all OK.
[2] In slack compilation mode it throws "local tVar_5", also OK?

I think so. The point is:  *** "do" recompiles ***.
Thus line 3 with x=5, what is "local tVar_5", is offending in that re-compilation,
because tVar_5 is already implicitly declared in line 6 of first compilation.

> .. It may be be counter-productive to use <local> within a <do> statement
I would like to add to your advice the following line.

'This may help sometimes:  Read "do" as if it were on the end of current handler.'

=======
Hermann