this does not happen - it seems that the sub call takes the block as-is and returns a code reference. is there an explicit stringify operator for scalars? is this way feasible? my feeling says no, but i do not know it.

Don't confuse creating a closure with compilation. The closure's body is compiled at compile time, not when the closure gets created. The code of this closure says "stringify $j", but which$j is only decided at runtime. Creating a closure at runtime does not compile the code; it merely "connects" it with a specific instance of whichever lexicals it refers to. Since you only create a single $j, all your closures get "connected" to the same $j.

thanks to you both for clarification. in fact that is the way things are going.

the real problem i think is that the code gets created at compile time. stringification cannot happen since the code has not run yet. so variables stay what they are (even with a hypothetical stringification operator).

the same is for the anonymous sub enclosed in an eval (). i could imagine that stringification then works (if only the operator would exist) ... but an eval is expensive, and more than one eval is even more expensive ;)

(Note that if you don't quotemeta the variable, you open yourself up to all sorts of headaches - and a security hole if $j contains user input dependent data.)

But why would you want that? Just create a unique copy of the lexicals in question during each loop iteration and you'll be fine. There's no reason to resort to eval STRING for this job. As all others have already proposed: