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->()'
>
> print
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.
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 cur
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 s
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 preserve
On Sat, Sep 25, 2004 at 11:49:26AM -0700, Jeff Clites wrote:
: >It also makes up-call lexical peeking and modification impossible.
: >This is something Larry's specified Perl 6 code will be able to do.
: >
: >That is, any routine should be able to inspect the environment of its
: >caller, and mod
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 g
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 P6,
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 imp
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
i
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 the
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 could
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 s
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 PROTE
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, i
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 a
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 ig
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 w
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 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:
>
>
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 envir
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 ++
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
> assi
23 matches
Mail list logo
