On Sat, Feb 12, 2005 at 03:55:40PM -0500, Uri Guttman wrote: : LW> What's going on here is that the loop body is a closure that is : LW> cloned upon entry to the loop (you're logically passing a closure : LW> to the "for()" function that implements the loop), so if there's a : LW> FIRST inside, it runs each time the loop is initialized. Likewise : LW> state variables are logically regenerated for closure clones, so if : LW> use_first() above wants to have a state variable that is maintained : LW> from call to call, it must put it *outside* the loop. : : i am not clear on the actual answer. my take on what you said is that i : was right, FIRST will execute at the beginning of each time the loop is : entered which is what joe wants. am i correct?
Yes. : LW> Also, note that a LAST block, if any, has to be called from within : LW> the implementation of for(), since only for() knows when it's done : LW> with the loop as a whole. : : similarly for FIRST as only for() knows when it starts up the loop again : and reinitializes the counter. I think FIRST initialization happens automatically based on the cloning mechanism, and the fact that FIRST knows when it's first already. The code of a FIRST can actually be called inline, I think. Could be wrong about that. : LW> It will be an interesting problem for the optimizer to figure out : LW> how to avoid cloning closures that are passed only to synchronous : LW> loop-controller functions such as for() and not otherwise used : LW> asynchronously. Perhaps the signature of for() can make some : LW> guarantees about not squirreling away the closure pointer in : LW> some weird place. This is perhaps related to the issue of timely : LW> GC on pointers you know haven't been copied into outside storage. : : i see the problem. if the loop body refers to lexicals declared outside : it, it looks like a classic perl5 closure and would need to be : cloned. what about the fact that for() will be called in effectively a : void context? a classic closure makes sense only when the code ref is : saved or possible called immediately via (p5) ->. for() is called : immediately but with a different signature as you said. the void context : would help the optimizer since you don't save the code block for later : reuse, no cloning should be done. Doesn't really help--when you think about it, the block you pass to map or grep is also a loop block, and those generally aren't used in void context. It would have to be a marker on the actual block argument in the signature. Maybe based on type: sub mygrep (Block &block, [EMAIL PROTECTED]) {...} # don't clone sub mysched (Closure &block, [EMAIL PROTECTED]) {...} # clone Since the Block declaration would mostly be an optimizer hint, I suspect the default should be to clone, so the latter can just be written: sub mysched (&block, [EMAIL PROTECTED]) {...} # clone Actual type names are negotiable, of course. Maybe typename is the wrong place for that info, and it should just be sub mygrep (&block is uncloned, [EMAIL PROTECTED]) {...} # don't clone Or maybe it's just spelled with existing props: sub mygrep (&block is ref, [EMAIL PROTECTED]) {...} # don't clone sub mygrep (&block is copy, [EMAIL PROTECTED]) {...} # clone (default) Larry