Newsgroups: perl.perl6.internals
Path: g2news2.google.com!news1.google.com!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <pmich...@host.pmichaud.com>
Mailing-List: contact perl6-internals-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-intern...@perl.org
Received: (qmail 16681 invoked from network); 4 Aug 2007 02:52:02 -0000
Received: from x1a.develooper.com (HELO x1.develooper.com) (216.52.237.111)
  by lists.develooper.com with SMTP; 4 Aug 2007 02:52:02 -0000
Received: (qmail 7782 invoked by uid 225); 4 Aug 2007 02:52:02 -0000
Delivered-To: perl6-intern...@perl.org
Received: (qmail 7774 invoked by alias); 4 Aug 2007 02:52:01 -0000
X-Spam-Status: No, hits=-2.6 required=8.0
	tests=BAYES_00,DKIM_POLICY_SIGNSOME,DK_POLICY_SIGNSOME,SPF_PASS
X-Spam-Check-By: la.mx.develooper.com
Received-SPF: pass (x1.develooper.com: local policy)
Received: from pmichaud.com (HELO host.pmichaud.com) (38.119.121.196)
    by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Fri, 03 Aug 2007 19:51:58 -0700
Received: from pmichaud by host.pmichaud.com with local (Exim 4.52)
	id 1IH9k9-0003WB-Um
	for perl6-intern...@perl.org; Fri, 03 Aug 2007 21:51:53 -0500
Date: Fri, 3 Aug 2007 21:51:53 -0500
To: perl6-intern...@perl.org
Subject: Re: [perl #44395] Lexical scopes are too coarse-grained for loops
Message-ID: <20070804025153.GB31847@host.pmichaud.com>
References: <RT-Ticket-44395@perl.org> <18099.44441.633784.858589@rgrjr.dyndns.org> <rt-3.6.HEAD-23341-1186180659-269.44395-72-0@perl.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <rt-3.6.HEAD-23341-1186180659-269.44395-72-0@perl.org>
User-Agent: Mutt/1.4.2.1i
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.pmichaud.com
X-AntiAbuse: Original Domain - perl.org
X-AntiAbuse: Originator/Caller UID/GID - [32003 505] / [47 12]
X-AntiAbuse: Sender Address Domain - host.pmichaud.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Approved: n...@nntp.perl.org
From: pmich...@pobox.com (Patrick R. Michaud)

Perhaps ignore my earlier message -- this one is more coherent.

On Fri, Aug 03, 2007 at 03:37:39PM -0700, Bob Rogers wrote:
> 	sub make_closures_loop {
> 	    # Return $n closures, each with lexical references to $i and $n.
> 	    my $n = shift;
> 
> 	    my @result;
> 	    for (1..$n) {
> 		my $i = $_;
> 		push(@result, sub { print "Called sub $i out of $n.\n"; });
> 	    }
> 	    return @result;
> 	}
> 
>    Currently, the only way to get a distinct binding for each "$i" in
> PIR is to factor the loop body out into a separate lexical sub.  This is
> far from ideal, not least because it is not transparent to the HLL user.

Factoring the loop body out into a separate lexical sub is _exactly_
how Chip described to me that the above needed to be done.
Or, phrased differently, every lexical scope ends up requiring
its own parrot sub (with appropriate :outer pragmas), and the
compiler can optimize out such subs when it determines that there
aren't any new lexicals being declared within the loop body
(which somewhat comes down to keeping track of whether the loop
body contains any "my" declarations).

I'm not sure why this separate lexical sub has to be visible
to the HLL user -- the compiler ought to be able to make it appear
as though the sub isn't present.  (But I also bet that we can
come up with an example that makes it really hard to do that.)

>    Parrot should do better, IMHO.  The easiest way, it seems, would be
> to resurrect the push_pad and pop_pad instructions in some form.  [...]

I'd like for Parrot to be able to do better, yes, but I'm not
yet enough of an expert on closure handling to be able to
refute Chip's reasons for designing things this way.  I also
found the push_pad and pop_pad model somewhat easier to grasp
conceptually, but I recall Chip was fairly certain that they
wouldn't handle things in the generic case.

FWIW, the perl6 compiler currently treats _every_ block as a new 
lexical scope, and generates a separate Parrot sub for each.
At some point we will add an optimization so that blocks can
be inlined when the compiler determines that it's safe to do
so (based in part on the absence of any lexical declarations
within the block).

Hope this helps somewhat more than my previous message... :-)

Pm