William F Pokorny <ano### [at] anonymousorg> wrote:

> A quick aside I hope useful. A place where I've several times now gotten
> myself tangled up is with our relatively new #for loop. When you
> write:
>
>    #for (I,0,SphCnt,4)
>    ...
>    #end
>
> that 'I' is a created (or modified) identifier which persists. In the
> default yuqk build, it must be upper case, but I still forget that 'I'
> is not locally scoped to the for loop. If there is use of that 'I'
> outside the loop you can end up with an 'I' you didn't expect or, by
> accident, define an 'I' which should be defined / initialized in some
> other way.

This is something that I've run into as well, and for some reason I thought that
there was something in the docs that stated that loop inices were locally
scoped.  I could be wrong about that though.
I get nailed by this a lot when using functions, and I'm trying to use something
like "I" as a function parameter.  Grrr.

> One protection would be to add an '#undef I' immediately following the
> for loop when you are sure you don't need it to persist though I mostly
> fail to do it.
>
> I've though some about changing the implementation in yuqk so it does an
> internal #undef of the loop identifier / variable at loop's end, IF, the
> 'I' wasn't already defined. But, users sometimes would be doing things
> like breaking out and checking the 'I' value following the loop. I don't
> know... Just something to remember perhaps.

I definitely have code that I've written that does that and uses the final value
of I after the loop exits.

Perhaps something to consider is having #for or #while get invoked with an
option #undef flag, like we have shape macros that use union {} unless the "use
merge" flag is set.

If the flag gets set, you undef, if not, let it persist.
Or optionally, you could have the argument be an identifier that gets set to the
last I value - so the user is fully aware and intentionally releasing a globally
set variable into the wild.

Seems like maybe some of this just holds onto a can of worms and may encourage
poor coding practices.

I'm not sure what best practice is, but I personally would lean toward just the
locally encapsulated form.
I suppose if the ultimate I value is needed outside the loop, then the user can
(wastefully and continually) #declare an identifier (inside the loop) before
exiting.

Perhaps some other "real" language has a construct or programming paradigm that
best handles this?

- BW

Post a reply to this message