On Sun, Jun 12, 2005 at 11:26:49PM +0100, Piers Cawley wrote:
sub foo { my $x = 1; return sub { eval $^codestring } }
say foo()($x);
I'm pretty sure you meant single-quoted, and you perhaps might maybe
need a dot there:
sub foo { my $x = 1; return sub { eval $^codestring } }
On Mon, Jun 13, 2005 at 12:57:32AM +0200, Chip Salzenberg wrote:
On Sun, Jun 12, 2005 at 11:26:49PM +0100, Piers Cawley wrote:
sub foo { my $x = 1; return sub { eval $^codestring } }
say foo()($x);
I'm pretty sure you meant single-quoted, and you perhaps might maybe
need a dot
Rob Kinyon [EMAIL PROTECTED] writes:
Piers Cawley said:
in other words, some way of declaring that a subroutine wants to hang onto
every lexical it can see in its lexical stack, not matter what static
analysis
may say.
I'm not arguing with the idea, in general. I just want to point out
Rod Adams [EMAIL PROTECTED] writes:
Piers Cawley wrote:
Chip and I have been having a discussion. I want to write:
sub foo { my $x = 1; return sub { eval $^codestring } }
say foo()($x);
I claim that that should print 1. Chip claims it should throw a warning about
because of timely
On 6/12/05, Piers Cawley [EMAIL PROTECTED] wrote:
Chip and I have been having a discussion. I want to write:
sub foo { my $x = 1; return sub { eval $^codestring } }
say foo()($x);
I claim that that should print 1. Chip claims it should throw a warning about
because of timely
On Mon, Jun 13, 2005 at 11:24:07AM +, Luke Palmer wrote:
I just have to say that it's really annoying running into
optimizations when I don't want them.
Isn't the whole point of optimisations that you shouldn't have to worry
about whether you hit one or not, otherwise the optimisation
On 6/13/05, Paul Johnson [EMAIL PROTECTED] wrote:
On Mon, Jun 13, 2005 at 11:24:07AM +, Luke Palmer wrote:
Back when I wrote an
back-chaining system in perl, I used tied variables in order to
determine when I needed to solve for something. A
Chip and I have been having a discussion. I want to write:
sub foo { my $x = 1; return sub { eval $^codestring } }
say foo()($x);
I claim that that should print 1. Chip claims it should throw a warning about
because of timely destruction. My claim is that a closure should close over the
Piers Cawley said:
in other words, some way of declaring that a subroutine wants to hang onto
every lexical it can see in its lexical stack, not matter what static analysis
may say.
I'm not arguing with the idea, in general. I just want to point out
that this implies that you're going to hold
Piers Cawley wrote:
Chip and I have been having a discussion. I want to write:
sub foo { my $x = 1; return sub { eval $^codestring } }
say foo()($x);
I claim that that should print 1. Chip claims it should throw a warning about
because of timely destruction. My claim is that a closure
On Sun, Jun 12, 2005 at 11:26:49PM +0100, Piers Cawley wrote:
Chip and I have been having a discussion. I want to write:
sub foo { my $x = 1; return sub { eval $^codestring } }
say foo()($x);
I claim that that should print 1. Chip claims it should throw a warning
about because of
On Sun, Jun 12, 2005 at 06:22:22PM -0500, Rod Adams wrote:
Well, you could always do something like:
sub foo { my $x = 1; return sub {my $x := $OUTER::x; eval $^codestring} }
In perl5, that would just be
sub foo { my $x = 1; return sub { $x ; eval $_[0]} }
--
You live and learn
On 6/12/05, Dave Mitchell [EMAIL PROTECTED] wrote:
You may be using slow evals, but other fast code may not be. Should the
closure in
sub foo { my $x = 1; return sub { 1 } }
also capture the current instance of $x? You are basically condeming any
code that creates any closure, however
13 matches
Mail list logo
