Re: CLOS multiple dispatch
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 Nicol 816.235.1187 do be do be do
RE: What's up with %MY?
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 = 100;
{
my $x = (delete %MY::{'$x'}, $x+1);
print "inner=$x, ";
}
print "middle=$x, ";
}
print "outer=$x";
If delete 'reexposes' an outer version of that variable, then I'd speculate
the output would be
inner=51, middle=50, outer=50
Re: What's up with %MY?
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 file Localmodules.pm:
use Pollutte::Locally;
use Carp;
and in blarf.pl:
sub Carp {print "outer carp\n"};
{
use Localmodules.pm;
local *{$_} foreach @PolluteList;
Pollute();
Carp("Inner Carp"); # goes to STDERR
}
Carp(); #prints "outer carp\n"
Or is that just too complex. Local must be visible at compile-time
I suppose.
local use Carp;
is how local import should look IMO, that might have gotten into an RFC
--
David Nicol 816.235.1187
Refuse to take new work - finish existing work - shut down.
Re: What's up with %MY?
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;
> local *{$_} foreach @PolluteList;
> Pollute();
> Carp("Inner Carp"); # goes to STDERR
frok();# We want this to print "outer carp"
>
> }
>
> Carp(); #prints "outer carp\n"
>
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: What's up with %MY?
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";
>
> I'm guessing this prints inner=201, outer=200
Perhaps I missed something, but %MY:: refers to my lexical scope, and not my
parents, correct?
Why isn't this inner=201, outer=100?
>
> As for
>
> my $x = 50;
> {
> my $x = 100;
> {
> my $x = (delete %MY::{'$x'}, $x+1);
> print "inner=$x, ";
> }
> print "middle=$x, ";
> }
> print "outer=$x";
>
> If delete 'reexposes' an outer version of that variable, then I'd
> speculate the output would be
>
> inner=51, middle=50, outer=50
Again, I though that %MY:: referred to my current scope, in which case the
delete doesn't do anything. That would make it 101, 100, 50.
Is my understanding incorrect?
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: What's up with %MY?
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 scoped subs to spring into existence (and variables, for >that matter) will probably slow down sub and variable access, since we >can't safely resolve at compile time what variable or sub is being >accessed. Eh... isn't the main use for this, in import()? That's still compile time, isn't it? So you optimize it for compile time. Once compile time is over, the lexical variables table is frozen. If you want to add more stuff at runtime, it'll cost you. BTW if you add new variables at the back of the table, I don't see how any old references to existing variables would be compromised. -- Bart.
Re: What's up with %MY?
"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, $x+1);
> > print "inner=$x, ";
> > }
> > print "outer=$x";
> >
> > I'm guessing this prints inner=201, outer=200
>
> Perhaps I missed something, but %MY:: refers to my lexical scope, and not my
> parents, correct?
>
> Why isn't this inner=201, outer=100?
Because on the RHS of a 'my $x = ...' expression, $x is not yet in scope
(ie hasn't been "introduced"), so
my $x = 100; { my $x = $x+1; print $x }
prints 101, not 1 - the $x in the '$x+1' expression refers to the $x in the
outer scope.
I was just trying to confirm whether similar semantics apply to the use of
%MY:: - ie when used where a lexical has been defined but not yet introduced,
does %MY{'$x'} pick up the inner or outer lex?
I especially wanted to confirm whether delete %MY{'$x'} will delete the outer
$x because the inner one isn't yet quite in scope.
Re: What's up with %MY?
%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 PATH and execute the first perl found, but 'rm perl' will
not. It would only remove a perl in my current scope..., er, directory.
On Thursday 06 September 2001 08:28 am, Dave Mitchell wrote:
> > > 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
Oops, I may have been wrong. This might give you {some random number}, 100,
depending on how the reference is handled.
What you are, in essence, doing, is creating a lexical $x in my current
scope, and setting that to be a reference to 200. You're then taking that
newly created lexical $x, adding 1 to it (which currently is adding one to
the address of the constant, but whatever), and that is being stored in,
effectively, itself.
> >
>
> I was just trying to confirm whether similar semantics apply to the use of
> %MY:: - ie when used where a lexical has been defined but not yet
> introduced, does %MY{'$x'} pick up the inner or outer lex?
>
> I especially wanted to confirm whether delete %MY{'$x'} will delete the
> outer $x because the inner one isn't yet quite in scope.
The delete should be no-oppish, as the lexical variable doesn't exists yet
in the current lexical scope. If you want to mess with your parent's scope,
you have to mess with it directly, not indirectly.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: What's up with %MY?
"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 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'. Are your expectations different?
I think any further discussion hinges on that.
RE: What's up with %MY?
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, directory.
>
> 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'. Are your
> expectations different?
Hmm, shouldn't that print something like SCALAR(0x1b9289c)?
If you meant ${$MY::{'$x'}} then I'd agree...
Re: What's up with %MY?
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 something bugging me about this.
> >
> >Allowing lexically scoped subs to spring into existence (and variables, for
> >that matter) will probably slow down sub and variable access, since we
> >can't safely resolve at compile time what variable or sub is being
> >accessed.
>
>Eh... isn't the main use for this, in import()? That's still compile
>time, isn't it?
Sure, but the issue isn't compile time, it's runtime. The main use for
source filters was to allow compressed source, but look what Damian's done
with 'em... :)
>So you optimize it for compile time. Once compile time is over, the
>lexical variables table is frozen. If you want to add more stuff at
>runtime, it'll cost you.
Right. But since 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. (On the other hand, Simon and I were chatting and
I think we have a good solution, but it'll take some time to pan out)
>BTW if you add new variables at the back of the table, I don't see how
>any old references to existing variables would be compromised.
Well, if you have this:
my $foo = 'a';
{
{
%MY[-1]{'$foo'} = 'B';
print $foo;
}
}
(modulo syntax) should the print print a, or B? We bound to a $foo way
outside our scope, then injected a $foo in the middle.
Personally, I'd argue that it should print 'B'. Others may differ. I don't
care much, as long as I know what I should be doing at the internals level.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: What's up with %MY?
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 about when the compiler optimizes away a lexical with a constant? How about when the compiler optimizes away a sub call because it's side- effect-free and called with a constant? What about dead code elimination? What about when the compiler selects a register-based call op because of the prototype and then the sub gets replaced with an incompatible sub at run-time? What about inlining? We're not just talking symbol table frobbing. The whole ball of wax is on the table. > Personally, I'd argue that it should print 'B'. I totally agree. What's the point in injecting *broken* lexicals?! 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 really implemented using "Magical Disappearing Reappearing Surprise Your Friends Every Time" variables, so I guess we only have two kinds of variables... - Ken
Re: What's up with %MY?
> "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 with caller and getting the last scope.
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com
Search or Offer Perl Jobs -- http://jobs.perl.org
Re: What's up with %MY?
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 is that is illegal/meaningless in perl6. maybe you meant
>something with caller and getting the last scope.
Yup. I don't know that caller will be right when walking up plain block
scopes, so I punted on the syntax.
I could probably give you the bytecode... :)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: What's up with %MY?
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 really implemented using "Magical Disappearing Reappearing >Surprise Your Friends Every Time" variables, so I guess we only >have two kinds of variables... Not to put a damper on your rant here (and a nice one it was... :) but this is doable now. Heck, I can write a sub that completely rewrites the code for its caller at will now, in perl 5. Your code is only safe by convention. That safety isn't enforced in any way by the interpreter. I think you're also overestimating the freakout factor. You already have the easy potential for global variables and subroutines to change contents and behaviour at whim, and the world's not come to an end. If someone does go so far as to write a module that does truly bizarre and, more to the point, unexpected and undocumented things that nobody'll use it. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
what lexicals do?
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 introduction - a variable that has been defined but does
not yet mask an outer var, eg my $x = 1; { my $x = $x+1; ... }
* an inner sub referring to a lexical in a lexically enclosing outer sub
- ie closures.
* eval - ie delayed compilation of an inner sub with restored scope
* typed lexicals
* our
New in Perl 6:
* %MY:: dynmaically changing the values and visibility of lexicals
* lexically scoped named subs - so caller(){MY::}{'&die'} = &mydie does
something useful.
Re: What's up with %MY?
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 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. What worries me the most is that allowing %MY to change at run-time slows down code that doesn't do it. Maybe we can figure out how to reduce the impact, but that's time IMHO better spent making existing code run faster. 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 and location of $x will change. You really need to put the code for finding $x *inside the loop*. Maybe we can detect a few cases when it's safe to move get_lex out of a loop, but if the loop calls any subs or non-core ops we're stuck. - Ken
Re: what lexicals do?
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 called subroutines. This is true if it's the same subroutine called from itself or elsewhere--every call gets its own copy. - Ken
Re: What's up with %MY?
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 of a stated design goal this is. Most of the globals that are getting eliminated are mostly because of coarseness issues. ($/, say) >What worries me the most is that allowing %MY to change at run-time >slows down code that doesn't do it. Maybe we can figure out how >to reduce the impact, but that's time IMHO better spent making >existing code run faster. Maybe, but... with this sort of thing, if we know about it before we code, we're fine. It's one of the things worth spending some design time on. Even if we ultimately don't do it, I think it'll be time well spent. (There have been a number of features that have been discussed that ultimately were discarded, but thinking about them expanded the interpreter's design in pleasant ways) >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 and location of $x will change. You really need to put >the code for finding $x *inside the loop*. Only if $x is active. (i.e. tied) In that case we need to do some other things as well. I was assuming the passive case, for which the code was valid since there wasn't any way for it to be changed. >Maybe we can detect a few cases when it's safe to move >get_lex out of a loop, but if the loop calls any subs or >non-core ops we're stuck. Maybe. I think we're going to end up assuming ops have no side effects unless explicitly noted to have some, and those rules will be given to the compiler. As for subs, we do have to worry some, but we are in the nice position of being able to know if a sub does or doesn't change things globally. We're certainly not limited to keeping C's pathetic "just parameters" as the only metadata stored about functions. We can have "uses string eval", "uses MY", "OK but calls x, y, and Z", or whatever stored for each sub so we can have an idea of what alters things. Now, granted, it might be such that a single "uses string eval" or "uses MY" in the program shuts down optimization the same way that $& kills RE performance in perl 5, but we are in the position of tracking that. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: What's up with %MY?
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 tiny clue about what
> happened.
>
> 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.
Would it be possible/desirable to have 'static' and 'dynamic' properties for
lexical scopes? Could we have static lexical scopes for things that can be
resolved before runtime, yet could be explicitly promoted to dynamic scopes
at runtime if needed?
Speaking from a solid position of ignorance, I must ask: does supporting one
exclude support for the other?
is static|dynamic {
my $pop = 0;
sub incr { ++$pop }
}
Re: What's up with %MY?
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 and location of $x will change. You really need to put
> >the code for finding $x *inside the loop*.
>
> Only if $x is active. (i.e. tied) In that case we need to do some other
> things as well. I was assuming the passive case, for which the code was
> valid since there wasn't any way for it to be changed.
Could you compile the following for us with the assumption that
g() does not change its' caller?
sub f {
my $sum = 0;
for (0..9) {
$sum += g()
}
$sum
}
Now what if g() is:
sub g {
my $parent = caller().{MY};
my $zero = 0;
$parent{'$sum'} = \$zero;
1
}
What if g() *appears* to be safe when perl compiles the loop, but
later on somebody replaces its' definition with the scope changing
one? Does perl go back and re-compile the loop?
The compiler could watch for uses of %MY, but I bet that most
modules will eventually use %MY to export symbols. Can the
compiler tell the difference between run-time and compile-time
usage of %MY?
> Now, granted, it might be such that a single "uses string eval" or "uses
> MY" in the program shuts down optimization the same way that $& kills RE
> performance in perl 5, but we are in the position of tracking that.
To quote Timone: "And you're okay with that?"
- Ken
Re: What's up with %MY?
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' definition with the scope changing >one? Does perl go back and re-compile the loop? Maybe. We might also do any number of other things, including refetching every time. 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. >The compiler could watch for uses of %MY, but I bet that most >modules will eventually use %MY to export symbols. Can the >compiler tell the difference between run-time and compile-time >usage of %MY? Sure. We scan the syntax tree after we're done with compilation, and if there aren't any MY accesses, we're OK. Mostly. do, require and string eval are still issues. > > Now, granted, it might be such that a single "uses string eval" or "uses > > MY" in the program shuts down optimization the same way that $& kills RE > > performance in perl 5, but we are in the position of tracking that. > >To quote Timone: "And you're okay with that?" Yes. "I shut off the optimizer and my code ran slow!" "Well, don't do that." Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: What's up with %MY?
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 only the *variable* and not
the value bound to the variable? Maybe I misunderstand a PMC, but
if the PMC represents a value, then re-binding a lexical should
create a new PMC and bind it to the variable.
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. exception: not enough Gnomes
I think I would expect behavior (c), but it's not obvious to me.
Anyways, it looks like you just reached the same conclusion I have: we
can't shadow a named variable in a non-PMC register. This might have
a surprising effect on the speed of
foreach (1..10)
vs.
foreach my $i (1..10)
- Ken
RE: What's up with %MY?
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. exception: not enough Gnomes
>
> I think I would expect behavior (c), but it's not obvious to me.
I would have said (c) as well.
And if I can figure it out... it ain't that tricky.
Re: What's up with %MY?
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'. Are your expectations
> different?
Yes. I would expect that to print 'undef'. '$x' doesn't exist as a key in
%MY::
>
> I think any further discussion hinges on that.
Yes. My expectations are different. My expectations are exactly like my
previous PATH example.
my $x = 100;
{
$MY::{'$x'} = 200; # Equivalent to 'my $x = 200'
print $x;
}
print $x;
That should print 200, and 100, should it not?
You are creating a lexical in the current scope, and assigning it the value
of 200. You are not finding a currently existing $x and assigning it the
value of 200, resulting in 200 / 200.
But let's be a little more pragmatic about it, shall we? Look beyond the
fire and brimstone for a moment. As Dan said, we can already screw up your
entire world. So other than a couple clever hacks from Damian, how will
they be used?
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 out of that scope's
symbol table. Very precise actions - not random reassignment of values from
hither and yon. Furthermore, unlike the value determination of a variable,
which meanders through the various scopes looking for the most applicable
target, %MY:: table manipulation is a singular entity, and needs to be
treated as such. You certainly don't want to be targetting random scopes
'n' levels up. You know exactly which level you need control over - 99% of
the time, the immediate parent - and that is where any change should be
limited too.
Believe it or not, this feature is designed to reduce action at a distance -
why would we want to create even more?
my $x = 100;
{
use some_pragma; # Introduces some $x
foo($x);
bar($x);
}
# The original pragma's scope has ended... why should we be using the
# same $x? We shouldn't. The $x was created in the inner scope, and
# we're back to ours
%MY:: access the pad, not the variable.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: What's up with %MY?
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, 3"
> e. exception: not enough Gnomes
>
> I think I would expect behavior (c), but it's not obvious to me.
SCALAR(addr),SCALAR(addr), 3
$$x,$$$y,$z = "3,3,3"
My $x container contains 1. ($x = 1)
My $y container contains a ref to the $x container. ($x = 1, $y = \$x)
My $z container contain 2. ($x = 1, $y = \$x, $z = 2)
My $x container now contains a ref to the $z container.
($x = \$z, $y = \$x, $z = 2)
My $z container now contains 3.
($x = \$z, $y = \$x, $z = 3, or $$x = 3, $$y = \$z, $z = 3, or
$$x = 3, $$$y = 3, $z = 3)
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: What's up with %MY?
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, $$y, $z\n"
> >
> > a. "2, 1, 3"
> > b. "2, 2, 3"
> > c. "3, 1, 3"
> > d. "3, 3, 3"
> > e. exception: not enough Gnomes
> >
> > I think I would expect behavior (c), but it's not obvious to me.
>
> I would have said (c) as well.
>
> And if I can figure it out... it ain't that tricky.
%MY:: ain't no different than %main::, except its contents are heaviliy
restricted to the current scope level. Whatever you used to be able to do
with globals, you'll now be able to do with lexicals. You just lose the
globalness of it.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: What's up with %MY?
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 container contain 2. ($x = 1, $y = \$x, $z = 2)
> My $x container now contains a ref to the $z container.
>($x = \$z, $y = \$x, $z = 2)
Bzzzt! The line:
%MY::{'$x'} = \$z;
assigns a reference to $z to the *symbol table entry* for $x, not to $x itself.
"3, 1, 3" is the correct answer.
Damian
Re: What's up with %MY?
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? Okay, I'll buy that for now.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: what lexicals do?
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 confusion. In other words,
have a lexical shadow a temporary (that's what we decided to call
locals, right?) when the temporary is asking for a name that has
been associated with a lexical.
Doing this takes two pieces. The first piece is package-justifying
any argument to C before replacing symbols with scratchpad
lookup hooks. The second is creating a lexical to hide the same-named
enclosing lexical and making it an alias to the new temporary.
perl -le'$Q=2;my$Q=3;print do{local$main::Q=4;($Q,$main::Q)},$Q,$main::Q'
Or did I miss the meeting where it was declared that temporaries
are just history.
It is not a big deal any way; can't think of a situation where this
would be useful.
--
David Nicol 816.235.1187
Refuse to take new work - finish existing work - shut down.
Re: What's up with %MY?
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 your "Perl 6 Overview" PDF slides. This stuff
changes *fast*, eh?
If I want to bind a sub, do I use:
%MY::{'&die'} = &my_die; # reference to sub my_die? (from slides)
or
%MY::{'&die'} = my_die; # magical symbol table assignment rule?
> "3, 1, 3" is the correct answer.
That's what I thought. Dan's not going to be happy. ;)
- Ken
Re: What's up with %MY?
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 magical stuff isn't it? Sorry I used the wrong syntax.
> I'm just taking it from your "Perl 6 Overview" PDF slides. This stuff
> changes *fast*, eh?
No, he was buzzing me. I was still thinking in terms of pads, and missed
the extra pointer. You were correct... Forget what you just
unremembered
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: What's up with %MY?
"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? 50% slower? Do you want the feature at any price? I don't like run-time frobbing of the symbol table. Not even precise tweaking. ;) I think it's in bad style and inconsistent with the purpose of lexicals. *But* bad style isn't a good argument and I wouldn't be pursuing this if it were just a style issue. The trouble lies in running the code. Lexicals used to be known at compile time. Now they can change practically anywhere. It's like using C and having *everything* be volatile. Except worse because you don't even know the address where something is going to be. A simple solution would be to allow lexical scope editing at compile time, but not run-time. Change a BEGIN block's caller() so that it is the scope being compiled instead of main. This achieves the majority of the benefits (lexical imports at compile time) without any downside. There are two other things that are easy to add. If the compiler knew in advance which lexicals might dynamically change, it could generate better code and not slow everything down. A trait called ":volatile" or something. IMHO this would also show intent to the people reading the code that something funny might happen to the variable. (Macros or compile-time injected lexicals could declare the :volatile trait, so I would imagine that some pretty interesting packages could still be written.) The other thing is to permit attaching attributes to a lexical scope. This allows undetected channels of communication between callees. There are interesting things that could be used for (carrying state between function calls in the same scope or simple thread-local storage). And It wouldn't impact compiled code at all. - Ken
