On Thursday 06 September 2001 06:16 am, Dave Mitchell wrote:
> One further worry of mine concerns the action of %MY:: on unintroduced
> variables (especially the action of delete).
>
> my $x = 100;
> {
> my $x = (%MY::{'$x'} = \200, $x+1);
> print "inner=$x, ";
> }
> print "outer=$x";
>
>
On Tue, 04 Sep 2001 18:38:20 -0400, Dan Sugalski wrote:
>At 09:20 AM 9/5/2001 +1100, Damian Conway wrote:
>>The main uses are (surprise):
>>
>> * introducing lexically scoped subroutines into a caller's scope
>
>I knew there was something bugging me about this.
>
>Allowing lexically scope
"Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> On Thursday 06 September 2001 06:16 am, Dave Mitchell wrote:
> > One further worry of mine concerns the action of %MY:: on unintroduced
> > variables (especially the action of delete).
> >
> > my $x = 100;
> > {
> > my $x = (%MY::{'$x'} = \200, $
%MY:: manipulates my lexical pad. If, to resolve a variable, I have to
search backwards through multiple pads (that's a metaphysical search, so as
to not dictate a physical search as the only behavior), that's a different
beastie.
Consider it like, oh, PATH and executables:
`perl` will search
"Bryan C. Warnock" <[EMAIL PROTECTED]> mused:
> Consider it like, oh, PATH and executables:
> `perl` will search PATH and execute the first perl found, but 'rm perl' will
> not. It would only remove a perl in my current scope..., er, directory.
But surely %MY:: allows you to access/manipulate v
From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
> "Bryan C. Warnock" <[EMAIL PROTECTED]> mused:
> > Consider it like, oh, PATH and executables:
> > `perl` will search PATH and execute the first perl
> > found, but 'rm perl' will not. It would only remove
> > a perl in my current scope..., er, dire
At 02:19 PM 9/6/2001 +0200, Bart Lateur wrote:
>On Tue, 04 Sep 2001 18:38:20 -0400, Dan Sugalski wrote:
>
> >At 09:20 AM 9/5/2001 +1100, Damian Conway wrote:
> >>The main uses are (surprise):
> >>
> >> * introducing lexically scoped subroutines into a caller's scope
> >
> >I knew there was
Dan Sugalski wrote:
> ... you have to take into account the possibility that a
> variable outside your immediate scope (because it's been defined in an
> outer level of scope) might get replaced by a variable in some intermediate
> level, things get tricky.
Other things get "tricky" too. How abou
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS>my $foo = 'a';
DS>{
DS> {
DS>%MY[-1]{'$foo'} = 'B';
DS>print $foo;
DS> }
DS> }
explain %MY[-1] please.
my impression is that is illegal/meaningless in perl6. maybe you meant
something w
At 11:51 AM 9/6/2001 -0400, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS>my $foo = 'a';
> DS>{
> DS> {
> DS>%MY[-1]{'$foo'} = 'B';
> DS>print $foo;
> DS> }
> DS> }
>
>explain %MY[-1] please.
>
>my impression
Hong Zhang wrote:
> How do you define the currently loaded? If things are lazy loaded,
> the stuff you expect has been loaded may not have been loaded.
We could load placeholders that go and load the bigger methods
as needed, for instance.
--
David
At 11:44 AM 9/6/2001 -0400, Ken Fox wrote:
>Yeah, I can see it now. Perl 6 has three kinds of variables:
>dynamically scoped package variables, statically scoped lexical
>variables and "Magical Disappearing Reappearing Surprise Your
>Friends Every Time" variables. Oh, and by the way, lexicals
>are
One further worry of mine concerns the action of %MY:: on unintroduced
variables (especially the action of delete).
my $x = 100;
{
my $x = (%MY::{'$x'} = \200, $x+1);
print "inner=$x, ";
}
print "outer=$x";
I'm guessing this prints inner=201, outer=200
As for
my $x = 50;
{
my $x =
Damian Conway wrote:
> proper lexically-scoped modules.
sub foo { print "outer foo\n"};
{
local *foo = sub {print "inner foo\n"};
foo();
};
foo();
did what I wanted it to. Should I extend Pollute:: to make
this possible:
in fi
On Thursday 06 September 2001 07:15 am, David L. Nicol wrote:
> in file Localmodules.pm:
>
> use Pollutte::Locally;
> use Carp;
>
> and in blarf.pl:
>
> sub Carp {print "outer carp\n"};
sub frok { Carp(); }
>
> {
> use Localmodules.pm;
>
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 06, 2001 at 11:05:37AM +0100, Dave Mitchell wrote:
> > I'm trying to get my head round the relationship between pad lexicals,
> > pad tmps, and registers (if any).
>
> It's exactly the same as the relationship between auto variables, C
> tempo
Dave Mitchell wrote:
> Hmmm, except that at the hardware level, registers can store the actual
> temporary values themselves
register struct value *hardware_registers_can_be_pointers_too;
The PMC registers act like pointer-to-struct registers. Other register
sets can hold immediate values. This
whoops, forgot to CC the list
- Begin Forwarded Message -
Date: Thu, 6 Sep 2001 14:32:19 +0100 (BST)
From: Dave Mitchell
Subject: Re: pads and lexicals
To: [EMAIL PROTECTED]
Content-MD5: iVd18ng5xfzBBgJHSPdShg==
Ken Fox <[EMAIL PROTECTED]> wrote:
> Dave Mitchell wro
Bart Lateur wrote:
> On Mon, 03 Sep 2001 19:29:09 -0400, Ken Fox wrote:
> > The concept isn't the same. "local" variables are globals.
>
> This is nonsense.
> ...
> How are globals conceptually different than, say, globally scoped
> lexicals? Your description of global variables might just as we
On Thu, Sep 06, 2001 at 02:35:53PM +0100, Dave Mitchell wrote:
> The Perl equivalent $a = $a + $a*$b requires a
> temporary PMC to store the intermediate result ($a*$b)
Probably a temporary INT or NUM register, in fact. But I see
your point. I wouldn't be surprised if some of the PMC registers
ha
On Mon, 03 Sep 2001 19:29:09 -0400, Ken Fox wrote:
>> *How* are they "fundamentally different"?
>
>Perl's "local" variables are dynamically scoped. This means that
>they are *globally visible* -- you never know where the actual
>variable you're using came from. If you set a "local" variable,
>all
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 06, 2001 at 02:35:53PM +0100, Dave Mitchell wrote:
> > The Perl equivalent $a = $a + $a*$b requires a
> > temporary PMC to store the intermediate result ($a*$b)
>
> Probably a temporary INT or NUM register, in fact. But I see
> your point. I w
Dave Mitchell wrote:
> The Perl equivalent $a = $a + $a*$b requires a
> temporary PMC to store the intermediate result ($a*$b). I'm asking
> where this tmp PMC comes from.
The PMC will stashed in a register. The PMC's value will be
stored either on the heap or in a special memory pool reserved
fo
On Thu, Sep 06, 2001 at 02:54:29PM +0100, Dave Mitchell wrote:
> So I guess I'm asking whether we're abandoning the Perl 5 concept
> of a pad full of tmp targets, each hardcoded as the target for individual
> ops to store their tmp results in.
Not entirely; the last thing we want to be doing is c
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 06, 2001 at 02:54:29PM +0100, Dave Mitchell wrote:
> > So I guess I'm asking whether we're abandoning the Perl 5 concept
> > of a pad full of tmp targets, each hardcoded as the target for individual
> > ops to store their tmp results in.
>
> N
On Sun, Sep 02, 2001 at 11:56:10PM +0100, Simon Cozens wrote:
> Here's the first of a bunch of things I'm writing which should give you
> practical information to get you up to speed on what we're going to be doing
> with Parrot so we can get you coding away. :) Think of them as having a
> Apocaly
Dave Mitchell wrote:
> So how does that all work then? What does the parrot assembler for
>
> foo($x+1, $x+2, , $x+65)
The arg list will be on the stack. Parrot just allocates new PMCs and
pushes the PMC on the stack.
I assume it will look something like
new_pmc pmc_register[0]
a
Simon Cozens wrote:
> I want to get on with writing all the other documents like this one, but
> I don't want the questions raised in this thread to go undocumented and
> unanswered. I would *love* it if someone could volunteer to send me a patch
> to the original document tightening it up in the
On Thu, Sep 06, 2001 at 10:46:56AM -0400, Ken Fox wrote:
> Sure. I can do that while *waiting patiently* for Parrot to be
> released. ;)
Don't tell Nat I said this, but we're hoping for around the
beginning of next week.
Simon
At 10:44 AM 9/6/2001 +0200, Bart Lateur wrote:
>On Mon, 03 Sep 2001 19:30:33 -0400, Dan Sugalski wrote:
>
> >The less real question, "Should pads be hashes or arrays", can be answered
> >by "whichever is ultimately cheaper". My bet is we'll probably keep the
> >array structure with embedded names,
At 10:41 AM 9/6/2001 +0200, Bart Lateur wrote:
>Firs of all, currently, you can localize an element from a hash or an
>array, even if the variable is lexically scoped.
This doesn't actually have anything to do with lexicals, globals, or pads.
And the reason the keyword local works on elements of
On Mon, 03 Sep 2001 19:30:33 -0400, Dan Sugalski wrote:
>The less real question, "Should pads be hashes or arrays", can be answered
>by "whichever is ultimately cheaper". My bet is we'll probably keep the
>array structure with embedded names, and do a linear search for those rare
>times you're
At 10:45 AM 9/6/2001 -0400, Ken Fox wrote:
>Dave Mitchell wrote:
> > So how does that all work then? What does the parrot assembler for
> >
> > foo($x+1, $x+2, , $x+65)
>
>The arg list will be on the stack. Parrot just allocates new PMCs and
>pushes the PMC on the stack.
No, it won't ac
At 05:08 PM 9/5/2001 -0500, David L. Nicol wrote:
>what if:
>
> *> there is a way to say that no new classes will be introduced
Then pigs will probably be dive-bombing the Concorde, and demons ice
skating. This is the language Damian programs in, after all... :)
At 03:21 PM 9/6/2001 +0100, Dave Mitchell wrote:
>Simon Cozens <[EMAIL PROTECTED]> wrote:
> > On Thu, Sep 06, 2001 at 02:54:29PM +0100, Dave Mitchell wrote:
> > > So I guess I'm asking whether we're abandoning the Perl 5 concept
> > > of a pad full of tmp targets, each hardcoded as the target for
From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
Subject: pads and lexicals
>
> Dave "confused as always" M.
>
I just wanted to say that I'm really enjoying this pad/lexical thread.
There's a lot of info passing back and forth that I don't believe is clearly
documented in perlguts, etc. I expect
At 10:11 AM 9/6/2001 -0500, Garrett Goebel wrote:
>I just wanted to say that I'm really enjoying this pad/lexical thread.
>
>There's a lot of info passing back and forth that I don't believe is clearly
>documented in perlguts, etc. I expect when this thread runs its course,
>you'll be a whole lot
On 09/05/01 Nick Ing-Simmons wrote:
> >It's easier to generate code for a stack machine
>
> True, but it is easier to generate FAST code for a register machine.
> A stack machine forces a lot of book-keeping either run-time inc/dec of sp,
> or alternatively compile-time what-is-offset-now stuff
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> What we're going to do is have a get_temp opcode to fetch temporary PMCs.
> Where do they come from? Leave a plate of milk and cookies on your back
> porch and the Temp PMC Gnomes will bring them. :)
Ah, things are starting to make sense!
> ne
On 09/05/01 Dan Sugalski wrote:
> >It's easier to generate code for a stack machine
>
> So? Take a look at all the stack-based interpreters. I can name a bunch,
> including perl. They're all slow. Some slower than others, and perl tends
> to be the fastest of the bunch, but they're all slow.
H
At 05:00 PM 9/6/2001 +0100, Dave Mitchell wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > What we're going to do is have a get_temp opcode to fetch temporary PMCs.
> > Where do they come from? Leave a plate of milk and cookies on your back
> > porch and the Temp PMC Gnomes will bring them. :)
Paolo Molaro wrote:
> If anyone has any
> evidence that coding a stack-based virtual machine or a register one
> provides for better instructions scheduling in the dispatch code,
> please step forward.
I think we're going to have some evidence in a few weeks. I'm not
sure which side the evidence
I'm trying to get my head round the relationship between pad lexicals,
pad tmps, and registers (if any).
The PMC registers are just a way of allowing the the address of a PMC to
be passed to an op, and possibly remembered for soonish reuse, right?
So presumably we still have the equivalent of a
On Thu, Sep 06, 2001 at 12:13:11PM -0400, Dan Sugalski wrote:
> Hmmm. Yes, in fact it should. That code will end up with a list of 65
> identical scalars in it. Bad Dan! No cookie for me.
Damn. I guess that means we have to write a compiler after all. I was
looking forward to having Dan assemble
On 09/05/01 Hong Zhang wrote:
> I think we need to get some initial performance characteristics of register
> machine vs stack machine before we go too far. There is not much points left
> debating in email list.
Unfortunately getting meaningful figures is quite hard, there are
so many thing to t
At 06:12 PM 9/6/2001 +0200, Paolo Molaro wrote:
>On 09/05/01 Dan Sugalski wrote:
> > >It's easier to generate code for a stack machine
> >
> > So? Take a look at all the stack-based interpreters. I can name a bunch,
> > including perl. They're all slow. Some slower than others, and perl tends
> >
At 10:45 AM 09-06-2001 -0400, Ken Fox wrote:
>Dave Mitchell wrote:
> > So how does that all work then? What does the parrot assembler for
> >
> > foo($x+1, $x+2, , $x+65)
>
>The arg list will be on the stack. Parrot just allocates new PMCs and
>pushes the PMC on the stack.
>
>I assume it
(Firstly, I'd say trust Nick's expertise--he has spent a good-sized chunk
of his career doing software simulations of CPUs, and knows whereof he
speaks, both in terms of software running on hardware and software running
on software)
At 05:33 PM 9/6/2001 +0200, Paolo Molaro wrote:
>I believe th
Dan Sugalski wrote:
> > Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > Where do they come from? Leave a plate of milk and cookies on your back
> > > porch and the Temp PMC Gnomes will bring them. :)
> Bad Dan! No cookie for me.
You aren't fooling anybody anymore... You might just as well stop the
At 01:21 PM 9/6/2001 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > > Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > > Where do they come from? Leave a plate of milk and cookies on your back
> > > > porch and the Temp PMC Gnomes will bring them. :)
>
> > Bad Dan! No cookie for me.
>
>You aren't foo
At 06:12 PM 9/6/2001 +0200, Paolo Molaro wrote:
>As I said in another mail, I think the stack-based approach will not
>be necessarily faster, but it will allow more optimizations down the path.
>It may well be 20 % slower in some cases when interpreted, but if it allows
>me to easily JIT it and ge
Dave Mitchell:
# Simon Cozens <[EMAIL PROTECTED]> wrote:
# > On Thu, Sep 06, 2001 at 02:54:29PM +0100, Dave Mitchell wrote:
# > > So I guess I'm asking whether we're abandoning the Perl 5 concept
# > > of a pad full of tmp targets, each hardcoded as the
# target for individual
# > > ops to store t
On 09/06/01 Dan Sugalski wrote:
> >The original mono interpreter (that didn't implement all the semantics
> >required by IL code that slow down interpretation) ran about 4 times
> >faster than perl/python on benchmarks dominated by branches, function
> >calls,
> >integer ops or fp ops.
>
> Right
On 09/06/01 Dan Sugalski wrote:
> Okay, I just did a test run, converting my sample program from interpreted
> to compiled. (Hand-conversion, unfortunately, to C that went through GCC)
>
> Went from 2.72M ops/sec to the equivalent of 22.5M ops/sec. And with -O3 on
> it went to 120M ops/sec. The
On Thu, Sep 06, 2001 at 11:05:37AM +0100, Dave Mitchell wrote:
> I'm trying to get my head round the relationship between pad lexicals,
> pad tmps, and registers (if any).
It's exactly the same as the relationship between auto variables, C
temporaries and machine registers.
Simon
Dan Sugalski:
...
# new P0, list# New list in P0
# get_lex P1, $x # Find $x
# get_type I0, P1 # Get $x's type
# set_i I1, 1 # Set our loop var
# $10: new P2, I0 # Get a temp of the same type as $x
#
At 09:11 PM 9/6/2001 +0200, Paolo Molaro wrote:
>On 09/06/01 Dan Sugalski wrote:
> > >The original mono interpreter (that didn't implement all the semantics
> > >required by IL code that slow down interpretation) ran about 4 times
> > >faster than perl/python on benchmarks dominated by branches, f
At 09:22 PM 9/6/2001 +0200, Paolo Molaro wrote:
>A 10x slowdown on that kind of code is normal for an interpreter
>(where 10x can range from 5x to 20x, depending on the semantics).
If we're in the normal range, then, I'm happy.
Well, until we get equivalent benchmarks for Mono, in which case I s
At 12:34 PM 9/6/2001 -0700, Brent Dax wrote:
>Dan Sugalski:
>...
># new P0, list# New list in P0
># get_lex P1, $x # Find $x
># get_type I0, P1 # Get $x's type
># set_i I1, 1 # Set our loop var
># $10: new P2, I0
At 12:04 PM 9/6/2001 -0700, Brent Dax wrote:
>If foo is an unprototyped function (and thus takes a list in P0) we can
>immediately push the values of those calculations on to the list,
>something like (in a lame pseudo-assembler that doesn't use the right
>names for instructions):
FWIW, it's:
Dan Sugalski wrote:
> At 02:05 PM 9/6/2001 -0400, Ken Fox wrote:
> >You wrote on perl6-internals:
> >
> >get_lex P1, $x # Find $x
> >get_type I0, P1 # Get $x's type
> >
> >[ loop using P1 and I0 ]
> >
> >That code isn't safe! If %MY is changed at run-time, the
> >type
At 02:44 PM 9/6/2001 -0400, Ken Fox wrote:
>Could you compile the following for us with the assumption that
>g() does not change its' caller?
Maybe later. Pressed for time at the moment, sorry.
>What if g() *appears* to be safe when perl compiles the loop, but
>later on somebody replaces its' de
Dan Sugalski wrote:
> On the other hand, if we put the address of the lexical's PMC into a
> register, it doesn't matter if someone messes with it, since they'll be
> messing with the same PMC, and thus every time we fetch its value we'll Do
> The Right Thing.
Hmm. Shouldn't re-binding affect onl
From: Ken Fox [mailto:[EMAIL PROTECTED]]
>
> I think we have a language question... What should the following
> print?
>
> my $x = 1;
> my $y = \$x;
> my $z = 2;
> %MY::{'$x'} = \$z;
> $z = 3;
> print "$x, $$y, $z\n"
>
> a. "2, 1, 3"
> b. "2, 2, 3"
> c. "3, 1, 3"
> d. "3, 3, 3"
> e.
Here's a list of what any Perl 6 implementation of lexicals must be able to
cope with (barring additions from future apocalyses). Can anyone think of
anything else?
>From Perl 5:
* multiple instances of the same variable name within different scopes
of the same sub
* The notion of intr
On Thursday 06 September 2001 08:53 am, Dave Mitchell wrote:
> But surely %MY:: allows you to access/manipulate variables that are in
> scope, not just variables are defined in the current scope, ie
>
> my $x = 100;
> {
> print $MY::{'$x'};
> }
>
> I would expect that to print 100, not 'undef'
On Thursday 06 September 2001 05:52 pm, Ken Fox wrote:
> I think we have a language question... What should the following
> print?
>
> my $x = 1;
> my $y = \$x;
> my $z = 2;
> %MY::{'$x'} = \$z;
> $z = 3;
> print "$x, $$y, $z\n"
>
> a. "2, 1, 3"
> b. "2, 2, 3"
> c. "3, 1, 3"
> d. "3, 3
On Thursday 06 September 2001 06:01 pm, Garrett Goebel wrote:
> From: Ken Fox [mailto:[EMAIL PROTECTED]]
>
> > I think we have a language question... What should the following
> > print?
> >
> > my $x = 1;
> > my $y = \$x;
> > my $z = 2;
> > %MY::{'$x'} = \$z;
> > $z = 3;
> > print "$x
Bryan thought:
> > my $x = 1;
> > my $y = \$x;
> > my $z = 2;
> > %MY::{'$x'} = \$z;
> > $z = 3;
> > print "$x, $$y, $z\n"
>
> My $x container contains 1. ($x = 1)
> My $y container contains a ref to the $x container. ($x = 1, $y = \$x)
> My $z contai
On Thursday 06 September 2001 07:44 pm, Damian Conway wrote:
> Bzzzt! The line:
>
> %MY::{'$x'} = \$z;
>
> assigns a reference to $z to the *symbol table entry* for $x, not to $x
> itself.
So you're saying that the symbol table entry contains a reference to the
variable it represents? Oka
Dave Mitchell wrote:
>
> Here's a list of what any Perl 6 implementation of lexicals must be able to
> cope with (barring additions from future apocalyses). Can anyone think of
> anything else?
I would like
perl -le 'my $Q = 3; {local $Q = 4; print $Q}'
to print 4 instead of crashing in confu
Dan Sugalski wrote:
> I think you're also overestimating the freakout factor.
Probably. I'm not really worried about surprising programmers
when they debug their code. Most of the time they've requested
the surprise and will at least have a tiny clue about what
happened.
I'm worried a little abo
Dave Mitchell wrote:
> Can anyone think of anything else?
You omitted the most important property of lexical variables:
[From perlsub.pod]
Unlike dynamic variables created by the C operator, lexical
variables declared with C are totally hidden from the outside
world, including any calle
At 02:05 PM 9/6/2001 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
[stuff I snipped]
>I'm worried a little about building features with global effects.
>Part of Perl 6 is elimination of action-at-a-distance, but now
>we're building the swiss-army-knife-of-action-at-a-distance.
I don't know how much
From: Ken Fox [mailto:[EMAIL PROTECTED]]
> Dan Sugalski wrote:
> >
> > I think you're also overestimating the freakout factor.
>
> Probably. I'm not really worried about surprising programmers
> when they debug their code. Most of the time they've requested
> the surprise and will at least have a
Dan Sugalski:
# At 12:04 PM 9/6/2001 -0700, Brent Dax wrote:
# >If foo is an unprototyped function (and thus takes a list in
# P0) we can
# >immediately push the values of those calculations on to the list,
# >something like (in a lame pseudo-assembler that doesn't use the right
# >names for instr
At 01:43 PM 9/6/2001 -0700, Brent Dax wrote:
>Dan Sugalski:
># At 12:04 PM 9/6/2001 -0700, Brent Dax wrote:
># >In the more general case, however (say, $x*1+$x*2+...$x*65) that's an
># >interesting question. Could we just do some fun stuff with
># lists? What
># >do real CPUs do?
>#
># Real CPUs
On 09/06/01 Dan Sugalski wrote:
> Then I'm impressed. I expect you've done some things that I haven't yet.
The only optimizations that interpreter had, were computed goto and
allocating the eval stack with alloca() instead of malloc().
Of course, now it's slower, because I implemented the full s
I had a thought this morning on funtion/struct/global
prefixes for Parrot. If we really plan to also run
Python/Ruby/whatever on it, it does not look good for the
entire API to be prefixed with "perl_". We really (IMHO)
ought to pick something else so that we don't give people a
convenient target
Damian Conway wrote:
> Bzzzt! The line:
>
> %MY::{'$x'} = \$z;
>
> assigns a reference to $z to the *symbol table entry* for $x, not to $x itself.
So I should have said:
%MY::{'$x'} = $z;
That's pretty magical stuff isn't it? Sorry I used the wrong syntax.
I'm just taking it from yo
On Friday 07 September 2001 12:13 am, Ken Fox wrote:
> Damian Conway wrote:
> > Bzzzt! The line:
> >
> > %MY::{'$x'} = \$z;
> >
> > assigns a reference to $z to the *symbol table entry* for $x, not to $x
> > itself.
>
> So I should have said:
>
> %MY::{'$x'} = $z;
>
> That's pretty magic
"Bryan C. Warnock" wrote:
> Generically speaking, modules aren't going to be running amok and making a
> mess of your current lexical scope - they'll be introducing, possibily
> repointing, and then possibly deleting specific symbols
How much do you want to pay for this feature? 10% slower code?
82 matches
Mail list logo
