>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> : JG> The first time use_first is called it will print LW> : JG> entering loop LW> : JG> 1 LW> : JG> 2 LW> : JG> leaving loop LW> : LW> : JG> but subsequently it will print LW> : JG> 1 LW> : JG> 2 LW> : JG> leaving loop LW> : LW> : that seems to imply that FIRST is a program level first time action. i LW> : think it does what you want and is executed on the first iteration of a LW> : loop, each time the loop is started up. it is symmetrical to LAST in LW> : that way. it should print the former text each time the sub is called. 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? 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. 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. uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
