Re: What's up with %MY?
At 05:42 PM 9/12/2001 -0500, David L. Nicol wrote: >Uri Guttman can see a day where: > > python and ruby, etc. are > > defaulting to using the parrot back end as it will be faster, and > > compatible with perl etc. imagine the work reduction if all/most of the > > interpreted languages can share one common back end. > >What about the compiled ones? Did we consider and reject GCC back end >for reasons beyond "not-devloped-here?" We haven't rejected GCC--I'd actually be really thrilled if someone wanted to tie us into their code generator. (It's been on the long-term todo list since the middle of the middle of the first perl 6 organizational meeting) 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?
Uri Guttman can see a day where: > python and ruby, etc. are > defaulting to using the parrot back end as it will be faster, and > compatible with perl etc. imagine the work reduction if all/most of the > interpreted languages can share one common back end. What about the compiled ones? Did we consider and reject GCC back end for reasons beyond "not-devloped-here?" Inline.pm syntax is fully upgradable to a native back end instead of invoking external compilers, of course. -- David Nicol 816.235.1187 .sig file closed by executive order
Re: What's up with %MY?
"Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> 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?
I think you're confusing me with Ken Fox! At the moment, I'm just trying
to eke out of Damian what the precise semnatics of %MY:: will be, since
there are lots of possibilities. I'll join Ken in the Hellfire and Damnation
stakes after I've got a fixed target to aim at ;-)
Okay, personally I like the idea that %MY:: doesn't affect the values
or visibility (much) of outer scopes, since there's less
action-at-a-distance going on. The main drawback is that users may
find it counter-intuitive that you can't substitute $x in an expression
with %MY::{'$x'} and get the same result. But I guess they'll just
have to read the man page properly :-)
Anyway, in any particular scope, a variable $x can be in one of three states:
A) not defined, so '$x' refers to an outer lexical or global
B) defined but not introduced, and '$x' similarly refers to the outer value
(if any)
C) defined and introduced; '$x' refers to the local value.
Any manipulation of $::MY{'$x'} at compile or run time will have certain
effects in each of those 3 cases. Here's what I think all the permuations
should be.
... = %::MY{'$x'}
-
A,B: returns undef; C: returns ref to $x.
In no case is $x autovivified.
%::MY{'$x'} = \...
---
A@compile: equivalent of "my $x=..."
A@run: probably equivalent to "my $x=...", but we need to decide if affects
the visibility of previously compiled references to $x:
$x = 1; # package var
sub f { caller().{MY}{'$x'} = 2 if $_[0] }
sub g {
f(1);
$x; # does this see the lexical or the package var?
}
B,C: sets the lexical '$x' to the new value
delete %MY::{'$x'}
--
A,B: NOOP
C: marks the lexical as deleted. Any subsequent "...=$x" or "$x=..."
give a runtime error; subsequent "...=%MY::{'$x'} returns undef, while
a subsequent "%MY::{'$x'}=..." resurrects the variable with a new value.
Re: What's up with %MY?
At 12:13 AM 9/7/2001 -0400, Ken Fox wrote: >Damian Conway wrote: > > "3, 1, 3" is the correct answer. > >That's what I thought. Dan's not going to be happy. ;) Well, it means a fetch by pad entry rather than use of a cached PMC pointer, but that's OK by me. I have a solution for this that I'm perfectly comfortable with, so I'm fine. Once we've worked out how things should behave, then we can get on with implementing it. 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?
On Friday 07 September 2001 12:56 am, Ken Fox wrote: > "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? Which feature? The introduction of new lexicals solely at compile time? We can do that now. I've already demonstrated that this is a solvable problem. Although, admittedly, I wouldn't suggest actually *implementing* my solution, I'm sure someone far more clever than I can come up with a viable one. > > 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. But it clears up a *lot* of problems that were introduced with local. Much like perlfunc says... You really probably want to be using "my" instead, because "local" isn't what most people think of as "local". See the Private Variables via my() entry in the perlsub manpage for details. Lexicals were never about speed, they were about containership. A lot of Perl's magic and power, however, only work when centered around globals and locals. Muckings there, however, cause true "action at a distance" - what I change here for my benefit may screw something up way over there that I can't see. Allowing this to take place with lexicals reduces those risk factors - do your magic here and only here. > > 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. Lexicals being known at compile-time was a side-effect of the containership. Yes, we want lexicals to be fast. Containing behavior lexically is slightly more important, IMO. If it runs dog-slow, we won't do it. If it runs just a tad slower, we probably should. > > 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. Nope. Think 'require'. > > 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.) Except that magic will probably be going on behind the scenes, so you don't know it's magically. Otherwise, you'd just assign whatever it was to the lexical variable and be done with it -- 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
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?
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 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'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 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?
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 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?
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?
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?
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:
> 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?
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?
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?
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'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
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?
> "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?
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?
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?
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?
"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?
%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]> 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?
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?
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 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?
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?
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?
[EMAIL PROTECTED] wrote: > Clearly caller() isn't what we want here, but I'm not > quite sure what would be the correct incantation. I've always assumed that a BEGIN block's caller() will be the compiler. This makes it easy for the compiler to lie about %MY:: and use the lexical scope being compiled instead of the compiler's lexical scope. - Ken
RE: What's up with %MY?
Dan Sugalski <[EMAIL PROTECTED]> wrote
> >my $x = 1;
> >{
> > my $x = 2;
> > delete $MY::{'$x'};
> > print $x;
> > $mysub = sub {$x};
> >}
> >
> >print $mysub->();
> >
> >People seem agreed that print $x should do the equivalent of
> > throw "lexical '$x' no longer in scope"
>
> There might be less agreement than you might think. I wouldn't consider it
> unreasonable to search outward until I found a $x. (Perhaps going so far as
> to find a global if there were no lexical $x around)
>
> >rather than printing 1, but what should print $mysub->() do?
>
> Whatever inside would do, either throwing the error or walking out. I can
> see either way.
In either case, do people think that the behaviour should be consistent,
ie both walk or both throw?
I'm in favour walking, as long as we can get it so the walk is a one-off
fixup at delete time, and that any further accesses still just do the Perl 6
equivalent of
PL_curpad[PL_op->op_targ]
RE: What's up with %MY?
At 01:45 PM 9/5/2001 +0100, Dave Mitchell wrote:
>can I just clarify something about delete:
>
>my $x = 1;
>{
> my $x = 2;
> delete $MY::{'$x'};
> print $x;
> $mysub = sub {$x};
>}
>
>print $mysub->();
>
>People seem agreed that print $x should do the equivalent of
> throw "lexical '$x' no longer in scope"
There might be less agreement than you might think. I wouldn't consider it
unreasonable to search outward until I found a $x. (Perhaps going so far as
to find a global if there were no lexical $x around)
>rather than printing 1, but what should print $mysub->() do?
Whatever inside would do, either throwing the error or walking out. I can
see either way.
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?
can I just clarify something about delete:
my $x = 1;
{
my $x = 2;
delete $MY::{'$x'};
print $x;
$mysub = sub {$x};
}
print $mysub->();
People seem agreed that print $x should do the equivalent of
throw "lexical '$x' no longer in scope"
rather than printing 1, but what should print $mysub->() do?
I'd like it to also throw the same error, preferably at clone time.
Comments?
RE: What's up with %MY?
Garrett Goebel <[EMAIL PROTECTED]> wrote
> From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
> > sub Foo::import {
> > my %m = caller(1).{MY}; # or whatever
> > %m{'$x'} = 1;
> > }
...
> > sub f {
> > my $x = 9;
> > use Foo; # does $x become 1, or $x redefined, or runtime
> > # error, or ... ?
>
> do you mean Foo::import()? 'use' is handled like:
>
> BEGIN {
> require Foo;
> Foo::import(@_);
> }
>
> So 'use Foo' would modify the caller, which being processed at compile time
> would be 'main'. So this would create a my $x in the scope of the main_cv.
> Which would then be removed by the later 'use Bar'.
I meant 'use Foo', in the sense of wanting (at compile time) to modify the
lexical state of the place where 'use' appears (ie f()), since this
appears to be the main reason why people wanted the %MY:: feature in the
first place. Hence the "or whatever" comment in the vague, hand-waving
"my %m = caller(1).{MY}" bit. Clearly caller() isn't what we want here, but
I'm not quite sure what would be the correct incantation.
Re: What's up with %MY?
Ken Fox wrote:
> Modifying the caller's environment:
>
> $lexscope = caller().{MY};
> $lexscope{'&die'} = &die_hard;
>
> is especially annoying because it means that I can't
> trust lexical variables anymore.
You think you can trust them now? :-)
The PadWalker module (on CPAN) allows a subroutine to modify its
caller's lexicals in exactly this way. I wrote it some time ago, and it
hasn't yet precipitated the apocalypse :-)
.robin.
--
Straw? No, too stupid a fad! I put soot on warts.
Re: What's up with %MY?
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: DC> Dan concluded: >> Certainly doable. Just potentially slow, which is what I'm worried >> about. Making it not slow has both potential significant complexity >> and memory usage. If we have to, that's fine. Just want to make >> sure the cost is known before the decision's made. :) DC> I rather liked the DC> "delete-means-install-a-pad-walking-placeholder" notion. That way DC> things only get slow if you actuallt do something evil. but that doesn't cover adding something into the parent scope. that can't fit into the pad since it was preallocated and has no slot for the new symbol. maybe then a hash based pad is added and checked first/last. again, this is a majro slowdown. even with a linear pad, if a lower scope references a parent, it has to do a linear search. what about a similar idea to the above, add a hash based pad whenever the pad set of symbols is changed (deletes or additions). the original pad is still used for code compiled in the pad's scope so those vars are always found with a pad offset and are fast. the first time you do something to a pad from another scope, a hash of it is made and attached to the pad. that hash is used for all external access to %MY::. seems like a win as it only penalizes the users of %MY:: in another scope and which modify its symbol table. and then the hash is a speedup for later uses of that pad. another way to look at it is that compiled code in a scope uses compile time pad offsets and external access to a pad at runtime is via a hash. the hash entries for the compiled symbols refer to pad offsets and the others are stored in the hash itself. i can't believe i got sucked into this thread. :) 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?
Damian wrote:
> In other words, everything that Exporter does, only with lexical
> referents not package referents. This in turn gives us the ability to
> easily write proper lexically-scoped modules.
Great! Then we don't need run-time lexical symbol table
frobbing. A BEGIN block can muck with its' callers symbol
table at compile time.
> I can image a Lexically::Verbose module, that modifies all variables and/or
> subroutines in a scope to report their own activity:
>
> while (whatever) {
> use Lexically::Verbose 'vars';
Another compile time example.
> In fact, you just invented a new pattern, in
> which a set of subroutines called within a scope can communicate invisibly
> but safely through that scope's lexical symbol table.
Hey, don't make me an accomplice in this... ;)
> Accessing lexicals will be no slower than accessing package variables
> is today.
Actually I'm not sure about that. Package variables only work well
because they have global definitions. Lexicals don't. IMHO in order
to have the speed of package variables, we'll have to make lexical
scope changes trigger a re-compile (at least a re-link) of the
affected code. Besides, I was hoping for Perl 6 lexicals to be a
great deal *faster* than package variables...
How much stuff currently depends on dynamic lexicals? (Ugh. Why
are we even *talking* about something that horrible.) If there were
a pragma to eliminate them, would it break much?
- Ken
Re: What's up with %MY?
At 10:23 PM 9/4/2001 -0400, Ken Fox wrote: >Efficiency is a real issue! I've got 30,000 lines of *.pm in my >latest application -- another 40,000 come from CPAN. The lines >of code run a good deal less, but it's still a pretty big chunk >of Perl. > >The thought of my app suddenly running slower (possibly *much* >slower after seeing the semantics of Perl 6 lexicals) doesn't >make me real happy. IMHO it would fork the language, even if >the fork was only done with pragmas. I still have the "perl 6 must run faster than perl 5" mandate. Things *will* be faster. Somehow. We may have to do Weird Magic (or I have to convince Larry that demonstrated performance won't get any better) but I think we can get there. I think we're going to have to sacrifice some memory for it, though. 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?
On Tuesday 04 September 2001 10:10 pm, Dan Sugalski wrote: > At 08:59 PM 9/4/2001 -0400, Bryan C. Warnock wrote: > >Yes, this is akin to redeclaring every lexical variable every time you > >introduce a new scope. Not pretty, I know. But if you want run-time > >semantics with compile-time resolution > > That is exactly what it is, alas. If we allow lexicals to get injected in, > we need to either do this (Basically having every non-package variable > getting an entry in the scope's pad) or search backward. I don't much like > either option, but I think this is the best of the lot. > > So much for the "Extra braces don't carry any runtime penalty to speak of" > speech in class... :) Well, they still wouldn't. Mostly. All the pads could *still* be set up at compile time. All lexicals within a scope would be grouped together, which might (doubtful) help reduce paging. If pads were still arrays, the original construction would consist of memcopys - about as cheap of duplication that you'll get. And the performance hits would be taken only by a) the unqualified globals, and b) the actual twiddling of the lexical variables (both in lookup, and in manipulation). If you're going to take hits, that's where to take them. Of course, then you've got the bloat to worry about. Which might make your decision to go ahead and be slow an easy one But why are we on the language list for this? Back to internals we go.. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: What's up with %MY?
Damian wrote: > Dan wept: >> 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. > > Understood. And that's why you get the big bucks. ;-) Efficiency is a real issue! I've got 30,000 lines of *.pm in my latest application -- another 40,000 come from CPAN. The lines of code run a good deal less, but it's still a pretty big chunk of Perl. The thought of my app suddenly running slower (possibly *much* slower after seeing the semantics of Perl 6 lexicals) doesn't make me real happy. IMHO it would fork the language, even if the fork was only done with pragmas. - Ken
Re: What's up with %MY?
At 12:00 PM 9/5/2001 +1100, Damian Conway wrote: >Dan concluded: > >> Certainly doable. Just potentially slow, which is what I'm worried >> about. Making it not slow has both potential significant complexity >> and memory usage. If we have to, that's fine. Just want to make >> sure the cost is known before the decision's made. :) > >I rather liked the "delete-means-install-a-pad-walking-placeholder" notion. >That way things only get slow if you actuallt do something evil. Insert needs one too. Or, rather, there needs to be one there already, and we may need to walk back pad by pad if a pad's changed. I think we're going to have to go with a doubly-linked tree structure for pads with some sort of runtime invalidation of fake entries when the pad itself is messed with. Have to think on that one a bit. 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 08:59 PM 9/4/2001 -0400, Bryan C. Warnock wrote: >Yes, this is akin to redeclaring every lexical variable every time you >introduce a new scope. Not pretty, I know. But if you want run-time >semantics with compile-time resolution That is exactly what it is, alas. If we allow lexicals to get injected in, we need to either do this (Basically having every non-package variable getting an entry in the scope's pad) or search backward. I don't much like either option, but I think this is the best of the lot. So much for the "Extra braces don't carry any runtime penalty to speak of" speech in class... :) 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?
On Tuesday 04 September 2001 08:32 pm, Dan Sugalski wrote:
> Absolutely nothing. The issue is speed. Looking back by name is, well,
> slow. The speed advantage that lexicals have is that we know both what pad
> a variable lives in and what offset in the pad it's living at. We don't
> have to do any runtime lookup--it's all compile time. If we lose that
> compile-time resolution, things get a lot slower. (Runtime lexical name
> lookup is a lot slower than runtime global lookup because we potentially
> have a lot of pads to walk up)
>
> Certainly doable. Just potentially slow, which is what I'm worried about.
> Making it not slow has both potential significant complexity and memory
> usage. If we have to, that's fine. Just want to make sure the cost is
> known before the decision's made. :)
Well, the ultimate trade-off for speed is memory. Right now, pads are
differential - what are the list of things that were defined in my lexical
scope. Those things are evaluated at compile-time to the pad ancestry (how
far up was something defined) and the pad offset (where within that pad) the
value of a lexical exists.
my $foo;
{
my $bar;
{
my $baz = $foo + $bar;
}
}
(Although I don't know why I'm explaining this to you, because you know this
far better than I do.)
Anyway, that's really...
[0][0];
{
[1][0];
{
[2][0] = [0][0] + [1][0];
}
}
# Pad 0 = [ foo ]
# Pad 1 = [ bar ]
# Pad 2 = [ baz]
...awful. But you get the idea.
Of course, you can't inject a new lexical foo at the inner-most loop because
it's already looking two pads up.
But what if we went ahead and made pads additive - comprehensive, so to
speak?
[0][0];
{
# Dup pad 0, and build on it.
[1][1];
{
# Dup pad 1, and build on it.
[2][2] = [2][0] + [2][1];
}
}
# Pad 0 = [ foo ]
# Pad 1 = [ foo, bar ]
# Pad 2 = [ foo, bar, baz ]
Yes, this is akin to redeclaring every lexical variable every time you
introduce a new scope. Not pretty, I know. But if you want run-time
semantics with compile-time resolution
Let's see what this buys us Enough for another gig of RAM, I hope.
To replace the innermost foo, all you do is change where [2][0] points.
To delete the innermost foo, all you do is replace it with the value from
the next most innermost foo, which (if you implement this as an array), at
the same offset. Of course, if the variable was introduced at that scope,
then you point to the global instead.
To add to the innermost scope Hmm. I'm not dumb enough to suggest
copying all the globals in there.. Okay, how about this? Package
qualified globals will always resolve in a global variable, so they continue
to handle lookups like before. So that leaves us unqualified globals to
take the brunt of the performance hit, which I'm okay with... so far.
Now, the unqualified globals need to first check to see if they've been
lexicalized. If they have been, they'd appear in the pad at an offset
beyond where the next higher pad left off. (Since otherwise, they'd have a
pad entry already.) Since most of the time, that would be empty, it'd only
be a brief glimpse before pursuing the global. If there are some, then it
would have to scan for itself, and use whatever was appropriate.
It's ugly but quick... er.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: What's up with %MY?
Dan concluded: > Certainly doable. Just potentially slow, which is what I'm worried > about. Making it not slow has both potential significant complexity > and memory usage. If we have to, that's fine. Just want to make > sure the cost is known before the decision's made. :) I rather liked the "delete-means-install-a-pad-walking-placeholder" notion. That way things only get slow if you actuallt do something evil. Damian
Re: What's up with %MY?
At 07:24 PM 9/4/2001 -0400, Bryan C. Warnock wrote:
>On Tuesday 04 September 2001 07:25 pm, Dan Sugalski wrote:
> > Ah, but what people will want is:
> >
> >my $x = "foo\n";
> >{
> > my $x = "bar\n";
> > delete $MY::{'$x'};
> > print $x;
> >}
> >
> > to print foo. That's where things get tricky. Though I suppose we could
> > put some sort of placeholder with auto-backsearch capabilities. Or
> > something.
>
>Other than the obvious run-time requirements of this, what's wrong with
>simply looking in the current pad, seeing it's not there, then looking in
>the previous pad...? (Assuming you know the variable by name)
Absolutely nothing. The issue is speed. Looking back by name is, well,
slow. The speed advantage that lexicals have is that we know both what pad
a variable lives in and what offset in the pad it's living at. We don't
have to do any runtime lookup--it's all compile time. If we lose that
compile-time resolution, things get a lot slower. (Runtime lexical name
lookup is a lot slower than runtime global lookup because we potentially
have a lot of pads to walk up)
Certainly doable. Just potentially slow, which is what I'm worried about.
Making it not slow has both potential significant complexity and memory
usage. If we have to, that's fine. Just want to make sure the cost is known
before the decision's made. :)
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 10:34 AM 9/5/2001 +1100, Damian Conway wrote: >Dan wept: > >> 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. >> >>[snippage] >> >> Not that I'm arguing against it, just that I can see some >> efficiency issues. > >Understood. And that's why you get the big bucks. ;-) I'm getting paid? Keen! :-P 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 wept: > 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. > >[snippage] > > Not that I'm arguing against it, just that I can see some > efficiency issues. Understood. And that's why you get the big bucks. ;-) Damian
RE: What's up with %MY?
Dan sighed:
> >I don't understand why you think that's particularly wormy?
>
> Ah, but what people will want is:
>
>my $x = "foo\n";
>{
> my $x = "bar\n";
> delete $MY::{'$x'};
> print $x;
>}
>
> to print foo. That's where things get tricky. Though I suppose we
> could put some sort of placeholder with auto-backsearch
> capabilities. Or something.
Exactly.
Damian
Re: What's up with %MY?
On Tuesday 04 September 2001 07:25 pm, Dan Sugalski wrote:
> Ah, but what people will want is:
>
>my $x = "foo\n";
>{
> my $x = "bar\n";
> delete $MY::{'$x'};
> print $x;
>}
>
> to print foo. That's where things get tricky. Though I suppose we could
> put some sort of placeholder with auto-backsearch capabilities. Or
> something.
Other than the obvious run-time requirements of this, what's wrong with
simply looking in the current pad, seeing it's not there, then looking in
the previous pad...? (Assuming you know the variable by name)
--
Bryan C. Warnock
[EMAIL PROTECTED]
RE: What's up with %MY?
At 10:04 AM 9/5/2001 +1100, Damian Conway wrote:
>Dan wrote:
>Why not C? It merely requires that the internals equivalent of:
[Snippy]
>I don't understand why you think that's particularly wormy?
Ah, but what people will want is:
my $x = "foo\n";
{
my $x = "bar\n";
delete $MY::{'$x'};
print $x;
}
to print foo. That's where things get tricky. Though I suppose we could put
some sort of placeholder with auto-backsearch capabilities. Or something.
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 wrote:
> At 12:50 PM 9/4/2001 -0500, Garrett Goebel wrote:
> >
> >So deleting it
> >would remove it from the scratchpad of &incr. But I would guess that
> >future calls to &incr would have to autovify $x in the scratchpad and
> >start incrementing it from 0. I.e., ignoring a package $x if it exists. I
> >could see people prefering it either way...
>
> Folks might also want that to then refer to the $x in the enclosing scope.
> Don't think that's going to happen, though. (Lots and lots of runtime
> overhead in that case)
I agree (both that people might want that, and that it's probably not
going to happen ;-)
> I can see allowing read/write/change/iterate access (possibly
> enforcing types when writing) but not delete. That opens up a
> number of cans of worms I'd rather stay closed for now.
Why not C? It merely requires that the internals equivalent of:
sub LEXICAL::SCALAR::FETCH ($varname) {
$scalar_ref = caller().{MY}{$varname};
return $$scalar_ref;
}
sub LEXICAL::SCALAR::STORE ($varname, $newval) {
$scalar_ref = caller().{MY}{$varname};
$$scalar_ref = $newval;
}
becomes:
sub LEXICAL::SCALAR::FETCH ($varname) {
$scalar_ref = caller().{MY}{$varname}
or throw "lexical $varname no longer in scope";
return $$scalar_ref;
}
sub LEXICAL::SCALAR::STORE ($varname, $newval) {
$scalar_ref = caller().{MY}{$varname}
or throw "lexical $varname no longer in scope";
$$scalar_ref = $newval;
}
I don't understand why you think that's particularly wormy?
Damian
Re: What's up with %MY?
>> What about if the symbol doesn't exist in the caller's scope
>> and the caller is not in the process of being compiled? Can
>> the new symbol be ignored since there obviously isn't any
>> code in the caller's scope referring to a lexical with that
>> name?
>
> No. Because some other subroutine called from the caller's scope might
> also access caller().{MY}. In fact, you just invented a new pattern,
in
> which a set of subroutines called within a scope can communicate
invisibly
> but safely through that scope's lexical symbol table.
Foxy variables. Nice.
Re: What's up with %MY?
Dave Mitchell asked:
> If there is to be a %MY, how does its semantics pan out?
That's %MY::. The colons are part of the name.
> for example, what (if anything) do the following do:
>
> sub Foo::import {
> my %m = caller(1).{MY}; # or whatever
> %m{'$x'} = 1;
> }
That would be:
sub Foo::import {
my $m = caller(1).{MY};
$m{'$x'} = \1;
}
Symbol table entries store references (to the actualy storage), not values.
My above example would make the lexical $x variable in the caller's scope
equivalent to:
my $x : const = 1;
> sub Bar::import {
> my %m = caller(1).{MY}; # or whatever
> delete %m{'$x'};
> }
That would be:
sub Bar::import {
my $m = caller(1).{MY};
delete $m{'$x'};
}
which would cause the next attempted access to the lexical $x in the
caller's scope to throw an exception.
> sub f {
> my $x = 9;
> use Foo; # does $x become 1, or $x redefined, or runtime error, or...?
$x becomes constant, with value 1.
> {
># is this the same as 'my $x = 1' at this point,
Yes.
># or is the outer $x modified?
No.
>use Foo;
>...
> }
Because %MY:: is lexical to each scope.
> use Bar; # is $x now still in scope?
No.
> print $x; #compile error? or runtime error? or prints 9 (or 1...)
Run-time exception.
> Bar::import(); # any difference calling it at run time?
No.
> IE what effects to do the standard hash ops of adding, modifying,
> deleting, testing for existence, testing for undefness, etc etc map onto
> when applied to some sub's %MY, at either compile or run time.
No difference between compile- and run-times.
Effects:
What Effect
add entry to %MY:: Creates new lexical in scope
modify entry in %MY::Changes implementation of lexical
delete entry in %MY: Prematurely removes lexical from scope
existence test entry in %MY::Does lexical exist in scope?
definition test entry in %MY:: Is lexical implemented in scope?
Damian
Re: What's up with %MY?
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. Take, for example:
my $foo;
my sub bar {print "baz\n"}
{
bang();
$foo = bar();
print $foo;
}
Now, what I want to do is to have bar() resolve to "previous pad, entry 2"
and bar to "previous pad, entry 1". Which they essentially do now. Those
lookups are snappy, at best we need to walk up the pad pointer chain. No
biggie.
However...
If we can inject lexicals into the caller's scope, bang() could add both a
$foo and a bar() inside the block. That means, for this to work right, I
*can't* resolve to a pad#/offset pair--instead I need to look up by name,
potentially every time. For any sort of speed I'd also need to do some sort
of caching scheme with multi-level snooping and cache invalidation, since
if the variables in question resolve in pad N at compile time, and I use
them at pad 0, I need to potentially check that pads 1-N have had changes
to them. I can see this making closures odd too, if I mess with pads at
runtime. (Odd in the "walking down from pad N just got more interesting" sense)
Not that I'm arguing against it, just that I can see some efficiency issues.
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?
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: DC> Thank-you. But I have to contend with the inflation of expectations. DC> Last year I wow'd them with simple quantum physics. This year, I needed DC> a quantum cellular automaton simulation of molecular thermodynamics DC> written in Klingon. What will it take next year??? DC> ;-) a fully functional perl6 in 1 page of self modifying (at the parser level, of course) perl6 code. hey, if lisp can do it, why not perl6? :) >> It vaguely worries me though that we'll be so far down the >> language side when implementation troubles arise that it will >> be hard to change the language. DC> I'm really not worried about that. Larry has consistently demonstrated DC> he's open to reassessing his design decisions when necessary. and there is nothing we are doing in the implementation so far that is restricting the language. we are actually making parrot more flexible to support other langauges. i can see a day where python and ruby, etc. are defaulting to using the parrot back end as it will be faster, and compatible with perl etc. imagine the work reduction if all/most of the interpreted languages can share one common back end. 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?
Ken wrote:
> Damian Conway wrote:
> > It would seem *very* odd to allow every symbol table *except*
> > %MY:: to be accessed at run-time.
>
> Well, yeah, that's true. How about we make it really
> simple and don't allow any modifications at run-time to
> any symbol table?
Err. No thanks. Being able to mess with the symbol table is one
of the things I most like about Perl.
> Can we have an example of why you want run-time
> symbol table manipulation? Aliases are interesting,
...but not what I had in mind.
The main uses are (surprise):
* introducing lexically scoped subroutines into a caller's scope
* introducing lexically scoped variables into a caller's scope
In other words, everything that Exporter does, only with lexical
referents not package referents. This in turn gives us the ability to
easily write proper lexically-scoped modules.
Other important uses are:
* modifying existing lexically scoped subroutines in a caller's scope
* modifying existing lexically scoped variables in a caller's scope
I can image a Lexically::Verbose module, that modifies all variables and/or
subroutines in a scope to report their own activity:
while (whatever) {
use Lexically::Verbose 'vars';
my $x; # logs: 'created $x at line 4''
$x++; # logs: 'incremented $x to 1 at line 5'
}
> >> Modifying the caller's environment:
> >>
> >> $lexscope = caller().{MY};
> >> $lexscope{'&die'} = &die_hard;
>
> This only modifies the caller's scope? It doesn't modify
> all instances of the caller's scope, right?
Right. Lexical symbol tables are themselves lexical variables. At the
end of the caller's scope, they vanish.
> For example, if I have an counter generator, and one of the
> generated closures somehow has its' symbol table modified, only
> that *one* closure is affected even though all the closures were
> cloned from the same symbol table.
Yep.
> What about if the symbol doesn't exist in the caller's scope
> and the caller is not in the process of being compiled? Can
> the new symbol be ignored since there obviously isn't any
> code in the caller's scope referring to a lexical with that
> name?
No. Because some other subroutine called from the caller's scope might
also access caller().{MY}. In fact, you just invented a new pattern, in
which a set of subroutines called within a scope can communicate invisibly
but safely through that scope's lexical symbol table.
> > Between source filters and Inline I can do pretty much whatever I like
> > to your lexicals without your knowledge. ;-)
>
> Those seem more obvious. There will be a "use" declaration
Not necessarily with Inline. Nor with source filters for that matter (the
C could be 500 lines and 10 nested scopes away at the top of the file)
> I wrote and I already know that "use" can have side-effects on
> my current name space. IMHO this could become a significant problem
> as we continue to make Perl more expressive. Macros, filters,
> self-modifying code, mini-languages ... they all make expressing
> a solution easier, and auditing code harder. Do we favor
> expression too much over verification?
I would have said that was Perl's signature feature. ;-)
> We also want Perl 6 to be fast and cleanly implemented.
Accessing lexicals will be no slower than accessing package variables
is today. Because in Perl 6 both lexicals and package variables will
use the same look-up mechanism: look up the appropriate symbol table
entry and that's your SV reference (or whatever replaces SVs in Perl 6).
Think of symbol table entries as vtables for variables.
> > How am I expected to produce fresh wonders if you won't let me warp the
> > (new) laws of the Perl universe to my needs?
>
> You constantly amaze me and everyone else. That's never
> been a problem.
Thank-you. But I have to contend with the inflation of expectations.
Last year I wow'd them with simple quantum physics. This year, I needed
a quantum cellular automaton simulation of molecular thermodynamics
written in Klingon. What will it take next year???
;-)
> One of the things that I haven't been seeing is the exchange
> of ideas between the implementation side and the language side.
> I've been away for a while, so maybe it's just me.
A great deal of that happens off-list: especially between Dan and I and
between Dan and Larry.
> It vaguely worries me though that we'll be so far down the
> language side when implementation troubles arise that it will
> be hard to change the language.
I'm really not worried about that. Larry has consistently demonstrated
he's open to reassessing his design decisions when necessary.
Damian
RE: What's up with %MY?
At 12:50 PM 9/4/2001 -0500, Garrett Goebel wrote:
> > sub Bar::import {
> > my %m = caller(1).{MY}; # or whatever
> > delete %m{'$x'};
> > }
>
>hmm... when:
>
>{ my $x = 1; sub incr {$x++} }
>
>is compiled, the $x++ in &incr refers to the lexical $x. So deleting it
>would remove it from the scratchpad of &incr. But I would guess that
>future calls to &incr would have to autovify $x in the scratchpad and
>start incrementing it from 0. I.e., ignoring a package $x if it exists. I
>could see people prefering it either way...
Folks might also want that to then refer to the $x in the enclosing scope.
Don't think that's going to happen, though. (Lots and lots of runtime
overhead in that case)
> >
> > IE what effects to do the standard hash ops of adding, modifying,
> > deleting, testing for existence, testing for undefness, etc
> > etc map onto when applied to some sub's %MY, at either compile
> > or run time.
>
>I would hope that it would be identical to the current behavior we
>experience when modifying a package's stash. Or however the new behavior
>for stashes maps to Perl6.
I can see allowing read/write/change/iterate access (possibly enforcing
types when writing) but not delete. That opens up a number of cans of worms
I'd rather stay closed for now.
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: Dave Mitchell [mailto:[EMAIL PROTECTED]]
>
> If there is to be a %MY, how does its semantics pan out?
>
> for example, what (if anything) do the following do:
>
> sub Foo::import {
> my %m = caller(1).{MY}; # or whatever
> %m{'$x'} = 1;
> }
IMO: Sets the value of the lexical $x in the caller's scope to 1,
autovifying '$x' if it doesn't exist.
> sub Bar::import {
> my %m = caller(1).{MY}; # or whatever
> delete %m{'$x'};
> }
hmm... when:
{ my $x = 1; sub incr {$x++} }
is compiled, the $x++ in &incr refers to the lexical $x. So deleting it
would remove it from the scratchpad of &incr. But I would guess that future
calls to &incr would have to autovify $x in the scratchpad and start
incrementing it from 0. I.e., ignoring a package $x if it exists. I could
see people prefering it either way...
> sub f {
> my $x = 9;
> use Foo; # does $x become 1, or $x redefined, or runtime
> # error, or ... ?
do you mean Foo::import()? 'use' is handled like:
BEGIN {
require Foo;
Foo::import(@_);
}
So 'use Foo' would modify the caller, which being processed at compile time
would be 'main'. So this would create a my $x in the scope of the main_cv.
Which would then be removed by the later 'use Bar'.
Assuming Foo::import(), I would guess that the $x which is local to &f would
be assigned the value 1.
> {
> # is this the same as 'my $x = 1' at this point,
> # or is the outer $x modified?
If you indeed meant 'use Foo', then the lexical $x of 'main' would be
created and set to 1.
Or, assuming you meant Foo::import() the answer would be neither. It would
neither modify the outer $x or create a new my $x, but modify the value of
the $x which exists within the scope of &f.
> use Foo;
> ...
> }
> use Bar; # is $x now still in scope?
'use Bar' would occur at compile time, and would remove the $x from main's
lexical scratchpad which had been created when you did 'use Foo'.
Or had you said Bar::import(): My guess would be that at this point, $x
would be removed from the stash of &f.
> print $x; #compile error? or runtime error? or prints 9
> #(or 1...)
If you used 'use Foo' and 'use Bar', it would print 9. Because the $x local
to &f would never have been touched.
If you meant Foo::import() and Bar::import() and had warnings turned on, it
would print:
Use of uninitialized value in print at ...
> Bar::import(); # any difference calling it at run time?
Yes... as mention above. One happens at compile, the other at runtime so the
caller and consequently lexical scope is different in each case.
> }
>
> and so on
>
> IE what effects to do the standard hash ops of adding, modifying,
> deleting, testing for existence, testing for undefness, etc
> etc map onto when applied to some sub's %MY, at either compile
> or run time.
I would hope that it would be identical to the current behavior we
experience when modifying a package's stash. Or however the new behavior for
stashes maps to Perl6.
Re: What's up with %MY?
If there is to be a %MY, how does its semantics pan out?
for example, what (if anything) do the following do:
sub Foo::import {
my %m = caller(1).{MY}; # or whatever
%m{'$x'} = 1;
}
sub Bar::import {
my %m = caller(1).{MY}; # or whatever
delete %m{'$x'};
}
sub f {
my $x = 9;
use Foo; # does $x become 1, or $x redefined, or runtime error, or ... ?
{
# is this the same as 'my $x = 1' at this point,
# or is the outer $x modified?
use Foo;
...
}
use Bar; # is $x now still in scope?
print $x; #compile error? or runtime error? or prints 9 (or 1...)
Bar::import(); # any difference calling it at run time?
}
and so on
IE what effects to do the standard hash ops of adding, modifying,
deleting, testing for existence, testing for undefness, etc etc map onto
when applied to some sub's %MY, at either compile or run time.
I'd be a lot happier about this concept if I knew how it was supposed
to behave!
Dave M.
RE: What's up with %MY?
From: Ken Fox [mailto:[EMAIL PROTECTED]]
>
> Can we have an example of why you want run-time
> symbol table manipulation?
How about being able to dump and restore subroutines and closures along with
their lexical environment?
Perhaps this next example doesn't have to fall under the runtime category,
but I personally would like to be able to use Perl5 attributes to take the
argument from an attribute specification's parameter list and convert it
from q{} into an anonymous subroutine with the same lexical context as the
subroutine implementation of which it is an attribute. Here's a contrived
example:
{
my $year = 2001;
sub year
: Pre($_[0] >= $year or die q{can't go back})
{ @_ ? $year = shift : $year }
}
> If the alias gets more complicated, I'm not sure the
> symbol table approach works well at all.
>
> >> Modifying the caller's environment:
> >>
> >> $lexscope = caller().{MY};
> >> $lexscope{'&die'} = &die_hard;
>
> This only modifies the caller's scope? It doesn't modify
> all instances of the caller's scope, right? For example,
> if I have an counter generator, and one of the generated
> closures somehow has its' symbol table modified, only that
> *one* closure is affected even though all the closures
> were cloned from the same symbol table.
In the example above, any future use of '&die' within the caller's lexical
scope would execute &die_hard instead of whatever &die used to refer to.
In your example it depends on whether by cloning you mean that each
generated closure has its own symbol table which is a copy of the values
from the original symbol table, or whether it is aliased to refer to the
same underlying values from the original symbol table.
> What about if the symbol doesn't exist in the caller's scope
> and the caller is not in the process of being compiled? Can
> the new symbol be ignored since there obviously isn't any
> code in the caller's scope referring to a lexical with that
> name?
My preference would be for autovification. That new symbols would be pushed
onto the scratchpad/symbol-table of the target lexical scope. Using another
contrived example in Perl5 syntax, what about:
{
my $foo = sub {'hello'};
sub say {
$foo;
my $a = eval qq{$_[0]};
eval(qq{\$$a})->();
};
}
print say('foo');
What if you'd like to insert an anonymous $bar subroutine into the
scratchpad of &say?
> Do we favor expression too much over verification? I'm
> not qualified to answer because I know I'm biased towards
> expression. (The %MY issues I'm raising mostly because of
> performance potential.)
What are the performance problems? Don't Cv's already have their own
scratchpads which could potentially by modified by code using Inline.pm or
XS code at runtime? It's not like we're adding anything new here... are we?
Isn't this just making something that is currently very difficult to do
easier?
> This particular issue is causing trouble because it has a big
> impact on local variable analysis -- which then causes problems
> with optimization. I'd hate to see lots of pragmas for turning
> features on/off because it seems like we'll end up with a more
> fragmented language that way.
Is this really a pragma issue?
I thought part of the Parrot thing was to allow simpler objects and their
associated vtables to be promoted to more complex ones. So we can have bells
and whistles, without having them impact performance until you start making
use of them. And then only affecting the performance of those objects which
are promoted. So write access to a Cv's local scope might done with one of
those scary polymorphic function objects which is less efficent than the
base function object where a function call is 'just a function call'.
Re: What's up with %MY?
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: DC> Dan revealed: >> That's easy--you slip the pumpking or internals designer a 10-spot. >> Amazing what it'll do... :) DC> And how do you think I got five of my modules into the 5.8 core??? i heard it was blackmail. you got a hold of pictures of jarkko's honeymoon. :-) 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?
Damian Conway wrote:
> It would seem *very* odd to allow every symbol table *except*
> %MY:: to be accessed at run-time.
Well, yeah, that's true. How about we make it really
simple and don't allow any modifications at run-time to
any symbol table?
Somehow I get the feeling that "*very* odd" can't be
fixed by making the system more normal. ;)
>> Is stuff like:
>>
>> %MY::{'$lexical_var'} = \$other_var;
>>
>> supposed to be a compile-time or run-time feature?
>
> Run-time.
A definition of run-time would help too since we have
things like BEGIN blocks. I consider it run-time if the
compiler has already built a symbol table and finished
compiling code for a given scope. Is that an acceptable
definition of run-time? This allows BEGIN blocks to
modify their caller's symbol tables even if we prohibit
changes at run-time.
Can we have an example of why you want run-time
symbol table manipulation? Aliases are interesting,
but symbol table aliases don't seem very friendly.
It would be simple to write:
%MY::{'@point'} = [ $x, $y ];
But that probably won't work and using [ \$x, \$y ]
doesn't make sense either. What seems necessary is:
%MY::{'$x'} = \$point[0];
%MY::{'$y'} = \$point[1];
If the alias gets more complicated, I'm not sure the
symbol table approach works well at all.
>> Modifying the caller's environment:
>>
>> $lexscope = caller().{MY};
>> $lexscope{'&die'} = &die_hard;
This only modifies the caller's scope? It doesn't modify
all instances of the caller's scope, right? For example,
if I have an counter generator, and one of the generated
closures somehow has its' symbol table modified, only that
*one* closure is affected even though all the closures
were cloned from the same symbol table.
What about if the symbol doesn't exist in the caller's scope
and the caller is not in the process of being compiled? Can
the new symbol be ignored since there obviously isn't any
code in the caller's scope referring to a lexical with that
name?
> Between source filters and Inline I can do pretty much whatever I like
> to your lexicals without your knowledge. ;-)
Those seem more obvious. There will be a "use" declaration
I wrote and I already know that "use" can have side-effects on
my current name space. IMHO this could become a significant problem
as we continue to make Perl more expressive. Macros, filters,
self-modifying code, mini-languages ... they all make expressing
a solution easier, and auditing code harder. Do we favor
expression too much over verification? I'm not qualified to
answer because I know I'm biased towards expression. (The %MY
issues I'm raising mostly because of performance potential.)
> I would envisage that mucking about with symbol tables would be no more
> common in Perl 6 than it is in Perl 5. But I certainly wouldn't want to
> restrict the ability to do so.
We also want Perl 6 to be fast and cleanly implemented.
This particular issue is causing trouble because it has a big
impact on local variable analysis -- which then causes problems
with optimization. I'd hate to see lots of pragmas for turning
features on/off because it seems like we'll end up with a more
fragmented language that way.
> How am I expected to produce fresh wonders if you won't let me warp the
> (new) laws of the Perl universe to my needs?
You constantly amaze me and everyone else. That's never
been a problem.
One of the things that I haven't been seeing is the exchange
of ideas between the implementation side and the language side.
I've been away for a while, so maybe it's just me.
It vaguely worries me though that we'll be so far down the
language side when implementation troubles arise that it will
be hard to change the language. Are we going to end up with
hacks in the language because certain Very Cool And Important
Features turned out too hard to implement?
- Ken
Re: What's up with %MY?
Dan revealed: > > How am I expected to produce fresh wonders if you won't let me > > warp the (new) laws of the Perl universe to my needs? > That's easy--you slip the pumpking or internals designer a 10-spot. > Amazing what it'll do... :) And how do you think I got five of my modules into the 5.8 core??? ;-) Damian
Re: What's up with %MY?
At 04:11 PM 9/4/2001 +1100, Damian Conway wrote: >I would envisage that mucking about with symbol tables would be no more >common in Perl 6 than it is in Perl 5. But I certainly wouldn't want to >restrict the ability to do so. > >How am I expected to produce fresh wonders if you won't let me warp the >(new) laws of the Perl universe to my needs? That's easy--you slip the pumpking or internals designer a 10-spot. Amazing what it'll do... :) 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?
> I haven't seen details in an Apocalypse, but Damian's
> Perl 6 overview has a bit about it. The Apocalypse
> specifically mentions *compile-time* scope management,
> but Damian is, uh, Damian. (DWIMery obviously. ;)
Hmm.
It would seem *very* odd to allow every symbol table *except*
%MY:: to be accessed at run-time.
> Is stuff like:
>
> %MY::{'$lexical_var'} = \$other_var;
>
> supposed to be a compile-time or run-time feature?
Run-time.
> Modifying the caller's environment:
>
> $lexscope = caller().{MY};
> $lexscope{'&die'} = &die_hard;
>
> is especially annoying because it means that I can't
> trust lexical variables anymore.
You can't trust them now.
Between source filters and Inline I can do pretty much whatever I like
to your lexicals without your knowledge. ;-)
> The one good thing about Damian's caller() example is that it
> appears in an import() function. That implies compile-time, but
> isn't as clear as Larry's Apocalypse.
I would envisage that mucking about with symbol tables would be no more
common in Perl 6 than it is in Perl 5. But I certainly wouldn't want to
restrict the ability to do so.
How am I expected to produce fresh wonders if you won't let me warp the
(new) laws of the Perl universe to my needs?
;-)
Damian
What's up with %MY?
I haven't seen details in an Apocalypse, but Damian's
Perl 6 overview has a bit about it. The Apocalypse
specifically mentions *compile-time* scope management,
but Damian is, uh, Damian. (DWIMery obviously. ;)
Is stuff like:
%MY::{'$lexical_var'} = \$other_var;
supposed to be a compile-time or run-time feature?
Modifying the caller's environment:
$lexscope = caller().{MY};
$lexscope{'&die'} = &die_hard;
is especially annoying because it means that I can't
trust lexical variables anymore. The one good thing
about Damian's caller() example is that it appears
in an import() function. That implies compile-time,
but isn't as clear as Larry's Apocalypse.
This feature has significant impact on all parts of
the implementation, so it would be nice if a little
more was known. A basic question: how much performance
is this feature worth?
- Ken
