develooper Front page | perl.perl6.language | Postings from February 2005

Re: Closure trait for loop entry

Thread Previous | Thread Next
From:
Uri Guttman
Date:
February 12, 2005 12:55
Subject:
Re: Closure trait for loop entry
Message ID:
x7is4xh50z.fsf@mail.sysarch.com
>>>>> "LW" == Larry Wall <larry@wall.org> 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  ------  uri@stemsystems.com  -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About