On Fri, Sep 24, 2004 at 09:30:22AM -0700, Steve Fink wrote:
But I agree that it is doing a name lookup in the string eval case.
Although if you try it, you get puzzling results:
perl -le 'sub x {my $foo = 1; return sub { eval q($foo++) } };$x=x();print
$x-(), $x-(), $x-()'
prints 012
On Sat, Sep 25, 2004 at 02:11:10PM -0400, Chip Salzenberg wrote:
: According to Dan Sugalski:
: At 12:25 PM -0400 9/25/04, Chip Salzenberg wrote:
: my $i is register;
:
: Except that makes things significantly sub-optimal in the face of
: continuations, since registers aren't preserved...
On Sat, Sep 25, 2004 at 10:01:42PM -0700, Larry Wall wrote:
: We've also said that MY is a pseudopackage referring to the current
: lexical scope so that you can hand off your lexical scope to someone
: else to read (but not modify, unless you are currently compiling
: yourself). However, random
On Sep 25, 2004, at 10:27 PM, Larry Wall wrote:
On Sat, Sep 25, 2004 at 10:01:42PM -0700, Larry Wall wrote:
: We've also said that MY is a pseudopackage referring to the current
: lexical scope so that you can hand off your lexical scope to someone
: else to read (but not modify, unless you are
Chip Salzenberg [EMAIL PROTECTED] wrote:
my $i is register;
I See A Great Need.
Well, the Perl6 notation is:
my int $i;
that even specifies, which kind of register is used. The caveat WRT
continuation still applies. And such natural typed variables aren't
stored in the lexical pad.
According to Jeff Clites:
But it's nice to have stuff that a compiler can optimize away in a
standard run, and maybe leave in place when running/compiling a
debug version [...]
my $i is register;
I See A Great Need.
--
Chip Salzenberg - a.k.a. - [EMAIL
At 12:25 PM -0400 9/25/04, Chip Salzenberg wrote:
According to Jeff Clites:
But it's nice to have stuff that a compiler can optimize away in a
standard run, and maybe leave in place when running/compiling a
debug version [...]
my $i is register;
I See A Great Need.
Except that makes things
At 7:43 PM -0700 9/24/04, Jeff Clites wrote:
On Sep 24, 2004, at 7:32 PM, Dan Sugalski wrote:
At 7:28 PM -0700 9/24/04, Jeff Clites wrote:
On Sep 24, 2004, at 6:51 PM, Aaron Sherman wrote:
However, the point is still sound, and that WILL work in P6, as I
understand it.
Hmm, that's too bad--it
According to Dan Sugalski:
That is, any routine should be able to inspect the environment of its
caller, and modify that environment, regardless of where the caller
came from.
Understood.
Leaf subs and methods can know [their call paths], if we stipulate
that vtable methods are on their
According to Dan Sugalski:
At 12:25 PM -0400 9/25/04, Chip Salzenberg wrote:
my $i is register;
Except that makes things significantly sub-optimal in the face of
continuations, since registers aren't preserved...
Well, I know I'd be willing to put in a few register declarations for
inner
At 2:10 PM -0400 9/25/04, Chip Salzenberg wrote:
According to Dan Sugalski:
Leaf subs and methods can know [their call paths], if we stipulate
that vtable methods are on their own, which is OK with me.
So, given this sub and tied $*var:
sub getvar { my $i = rand; $*var }
the FETCH method
On Sep 25, 2004, at 10:14 AM, Dan Sugalski wrote:
At 7:43 PM -0700 9/24/04, Jeff Clites wrote:
On Sep 24, 2004, at 7:32 PM, Dan Sugalski wrote:
At 7:28 PM -0700 9/24/04, Jeff Clites wrote:
On Sep 24, 2004, at 6:51 PM, Aaron Sherman wrote:
However, the point is still sound, and that WILL work in
On Sep 25, 2004, at 11:15 AM, Dan Sugalski wrote:
At 2:10 PM -0400 9/25/04, Chip Salzenberg wrote:
According to Dan Sugalski:
Leaf subs and methods can know [their call paths], if we stipulate
that vtable methods are on their own, which is OK with me.
So, given this sub and tied $*var:
sub
Hello,
I've been wondering for some time about this, so I thought, why not ask.
The thing is, I've been playing a few times with (Parrot, but also .NET)
compilers, and my conclusion was that the most difficult part is getting
assignments
right (when by value, when by ref, etc.). (that is, any
On Fri, Sep 24, 2004 at 04:03:46PM +0200, KJ wrote:
Hello,
I've been wondering for some time about this, so I thought, why not ask.
The thing is, I've been playing a few times with (Parrot, but also .NET)
compilers, and my conclusion was that the most difficult part is getting
On Fri, 2004-09-24 at 10:03, KJ wrote:
So, my question is, why would one need lexical pads anyway (why are they
there)?
They are there so that variables can be found by name in a lexically
scoped way. One example, in Perl 5, of this need is:
my $foo = 1;
return sub { $foo ++
At 4:03 PM +0200 9/24/04, KJ wrote:
So, my question is, why would one need lexical pads anyway (why are
they there)?
Pads do three things. First, as has been pointed out, they store
sufficient metadata so string evals (that's where code gets compiled
on the fly and accesses the surrounding
On Sep-24, Aaron Sherman wrote:
On Fri, 2004-09-24 at 10:03, KJ wrote:
So, my question is, why would one need lexical pads anyway (why are they
there)?
They are there so that variables can be found by name in a lexically
scoped way. One example, in Perl 5, of this need is:
my
On Sep 24, 2004, at 8:07 AM, Aaron Sherman wrote:
On Fri, 2004-09-24 at 10:03, KJ wrote:
So, my question is, why would one need lexical pads anyway (why are
they
there)?
They are there so that variables can be found by name in a lexically
scoped way. One example, in Perl 5, of this need is:
On Fri, 2004-09-24 at 12:36, Jeff Clites wrote:
Ha, you're example is actually wrong (but tricked me for a second).
Here's a simpler case to demonstrate that you can't look up lexicals by
name (in Perl5):
You are, of course, correct. If I'd been ignorant of that in the first
place, this
On Sep 24, 2004, at 6:51 PM, Aaron Sherman wrote:
On Fri, 2004-09-24 at 12:36, Jeff Clites wrote:
Ha, you're example is actually wrong (but tricked me for a second).
Here's a simpler case to demonstrate that you can't look up lexicals
by
name (in Perl5):
You are, of course, correct. If I'd been
At 7:28 PM -0700 9/24/04, Jeff Clites wrote:
On Sep 24, 2004, at 6:51 PM, Aaron Sherman wrote:
However, the point is still sound, and that WILL work in P6, as I
understand it.
Hmm, that's too bad--it could be quite an opportunity for
optimization, if you could use-and-discard lexical information
On Sep 24, 2004, at 7:32 PM, Dan Sugalski wrote:
At 7:28 PM -0700 9/24/04, Jeff Clites wrote:
On Sep 24, 2004, at 6:51 PM, Aaron Sherman wrote:
However, the point is still sound, and that WILL work in P6, as I
understand it.
Hmm, that's too bad--it could be quite an opportunity for
optimization,
23 matches
Mail list logo