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
to just register usage.)
There shouldn't be much, if any, pushing and popping for stuff like
this, and access to lexical pads should be an O(1) operation.
Remember, you know at compile time what lexical variables are in
scope which means if you have a data structure which can be accessed
by name
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
to be preserved at run-time. So a compiler could compile the above
into just some register stores and branches--no need to push new
lexical pads while inside the body of the sub, and that should be
_much_ faster without the pad manipulation overhead. (But if there
could be something like eval inside
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
to
locals, you're really just assigning to registers, not actually storing
variables in local pads. (and when registers run out, they're being spilled
to an array in P31, right?).
So, my question is, why would one need lexical pads anyway (why are they
there)?
Klaas-Jan
easily be done through PIR's .local syntax. However, when
assigning to
locals, you're really just assigning to registers, not actually storing
variables in local pads. (and when registers run out, they're being spilled
to an array in P31, right?).
So, my question is, why would one need lexical
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
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
ignorant of that in the first
place, this would be much less embarassing ;-)
No need to be embarrassed--it's easy to trick yourself. (I had
forgotten myself, until I recently tried it while thinking whether
lexical pads really needed a by-name API.)
However, the point is still sound
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
, you need
lexical pads as a feature in Parrot for...those cases where you need
lexical pads. 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--but that's a matter of the semantics of the language
While trying to generate a small example that shows the memory
corruption problem reported by Steve, I came along these issues:
a) [1] is .Sub, [2] is turned off
The subroutine prints main's $m - very likely wrong.
Q: Should the Sub get a NULL scratch pad, or a new empty scratch pad stack?
Leopold Toetsch writes:
While trying to generate a small example that shows the memory
corruption problem reported by Steve, I came along these issues:
a) [1] is .Sub, [2] is turned off
The subroutine prints main's $m - very likely wrong.
Well, Subs don't do anything with pads, so I'd
Will Coleda writes:
Can someone explain to me the lexical pad stack and static nesting
depth?
I'm trying to write global for tcl, and trying to pull out a variable
from the outermost pad, and failing to find it. - I'm fairly certain
this is because I'm abusing new_pad and store_lex
On Oct 16, 2003, at 10:53 PM, Will Coleda wrote:
I'm trying to write global for tcl, and trying to pull out a
variable from the outermost pad, and failing to find it.
Globals aren't stored in the lexical pads--there are find_global and
store_global ops (see var.ops)--is that what you
Can someone explain to me the lexical pad stack and static nesting
depth?
I'm trying to write global for tcl, and trying to pull out a variable
from the outermost pad, and failing to find it. - I'm fairly certain
this is because I'm abusing new_pad and store_lex (always using 0
as the static
in such a table. This is similar to the indexed access in
lexical pads. The implementation of both is totally different though.
First we should know, if $HL is likely to access lexicals/globals by
name or by index or mixed ...
Then such a pad or namespace table probably should be a separate PMC
class
29 matches
Mail list logo
