What's MY.line?
Chip Salzenberg
bit. A2 refers to C<MY> as a "pseudopackage" and says:
__LINE__ becomes MY.line
__FILE__ " MY.file
There is also Apocalypsal reference to C<%MY> as a name for the current
lexical symbol table.
First:
1. Is there any technical connection between C<MY> and C<%MY>?
I don't think there has to be. (Though I suppose you could
play entertaining tricks by manipulating C<%MY{MY}>.)
With regard to C<MY>:
2. What are "line" and "file"? Properties? Class variables?
(Probably not class variables since C<MY> is not called a class.)
And with regard to C<%MY>: Each function in Perl 5 has a single PAD that
could correspond to C<%MY>, except that PAD entries are indexed by a
combination of name and statement range. So:
3. Is C<%MY> intended to reflect the PAD?
3a. If so, how can one distinguish among the e.g. many C<my $foo>
variables declared within the current function?
3b. If not, how are lexical adjustments to C<%MY> unwound? Or are
they? If they're not, I can actually see the idea that could be
part of the base utility of C<%MY>.
3b1. But if they're not unwound, then the changes that *are* unwound
don't live in C<%MY>! For example:
if foo() { my $x = 1; print $x }
if bar() { my $x = 2; print $x }
The comings and goings of C<$x> in this code can't be
represented in C<%MY> (unless answer #3 above is "yes",
in which case this branch of questions is void).
Larry? Damian? Allison? ("Chief? McCloud?")
--
Chip Salzenberg - a.k.a. - <ch...@pobox.com>
"It furthers one to have somewhere to go."
Dave Mitchell
Based on what I rememeber from the long threads about this,
> 3. Is C<%MY> intended to reflect the PAD?
loosely speaking yes.
>
> 3a. If so, how can one distinguish among the e.g. many C<my $foo>
> variables declared within the current function?
It was decreed that %MY only sees stuff in the inner-most lexical scope
(so the Perl6 version of a pad is 'bigger' than what %MY sees):
{
my $x = 1;
{
exists %MY::{'$x'}; # false
print %MY::{'$x'}; # undef
print $x; # 1
%MY{'$x'} = 2;
print %MY::{'$x'}; # 2
print $x; # 2
{
exists %MY::{'$x'}; # false
print %MY::{'$x'}; # undef
print $x; # 2
}
}
exists %MY::{'$x'}; # true
print %MY::{'$x'}; # 1
print $x; # 1
}
>
> 3b. If not, how are lexical adjustments to C<%MY> unwound? Or are
> they? If they're not, I can actually see the idea that could be
> part of the base utility of C<%MY>.
I think the main intent of %MY:: is to allow import() to lexically affect
the caller, ie
sub import {
caller(1).MY{'&foo'} = sub { ... };
}
(for some vague handwaving interpretation of caller() and MY)
Dave.
--
My get-up-and-go just got up and went.
Dan Sugalski
> 3. Is C<%MY> intended to reflect the PAD?
Yes.
> 3a. If so, how can one distinguish among the e.g. many C<my $foo>
> variables declared within the current function?
One pad per block, rather than per sub.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
pdca...@bofh.org.uk
> At 9:50 PM -0400 7/9/02, Chip Salzenberg wrote:
> > 3. Is C<%MY> intended to reflect the PAD?
>
> Yes.
Hey! How's this for a scary thought:
$continuation.the_pad
I'll get my coat.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Melvin Smith
>Dan Sugalski <d...@sidhe.org> writes:
>
> > At 9:50 PM -0400 7/9/02, Chip Salzenberg wrote:
> > > 3. Is C<%MY> intended to reflect the PAD?
> >
> > Yes.
>
>Hey! How's this for a scary thought:
>
> $continuation.the_pad
>
>I'll get my coat.
Hah, good try!
I think this would be easy for Parrot. A continuation object will
have all of its context encapsulated already, including the lexical pad
stack.
Assuming the existence of this mystical beast, it could work like:
%continuation.the_pad{'$foo'}
-Melvin
Rafael Garcia-Suarez
> In (re?)examining the Apocalypses, I've found something that confuses me a
> bit. A2 refers to C<MY> as a "pseudopackage" and says:
>
> __LINE__ becomes MY.line
> __FILE__ " MY.file
>
>
> With regard to C<MY>:
>
> 2. What are "line" and "file"? Properties? Class variables?
> (Probably not class variables since C<MY> is not called a class.)
That's the implementation problem ;-)
In perl 5, __LINE__, __FILE__ and __PACKAGE__ are replaced at
compile-time (in fact, at tokenizing-time) by the appropriate constants.
The question is : to which kind of bytecode MY.file (etc.) get compiled ?
--
Rafael Garcia-Suarez : http://use.perl.org/~rafael/
Dan Sugalski
Well, unless they're accessible symbollically, there's no difference
between __LINE__ and MY.line. Just string constants to compare
against...
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> writes:
>
>> At 9:50 PM -0400 7/9/02, Chip Salzenberg wrote:
>> > 3. Is C<%MY> intended to reflect the PAD?
>>
>> Yes.
>
>Hey! How's this for a scary thought:
>
> $continuation.the_pad
What's that supposed to do, though? You want to alter the pad that
gets put in place at the top of the pad list for a continuation? No
problem. A bad idea, mind, but no problem... :)
pdca...@bofh.org.uk
> At 4:24 PM +0100 7/10/02, pdca...@bofh.org.uk wrote:
> >Dan Sugalski <d...@sidhe.org> writes:
> >
> >> At 9:50 PM -0400 7/9/02, Chip Salzenberg wrote:
> >> > 3. Is C<%MY> intended to reflect the PAD?
> >>
> >> Yes.
> >
> >Hey! How's this for a scary thought:
> >
> > $continuation.the_pad
>
> What's that supposed to do, though? You want to alter the pad that
> gets put in place at the top of the pad list for a continuation? No
> problem. A bad idea, mind, but no problem... :)
I was thinking it would get the pad of the block from which the
continuation was taken. But you're right, it's definitely one of those
'possible but almost certainly silly' ideas.
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> writes:
>
>> At 4:24 PM +0100 7/10/02, pdca...@bofh.org.uk wrote:
>> >Dan Sugalski <d...@sidhe.org> writes:
>> >
>> >> At 9:50 PM -0400 7/9/02, Chip Salzenberg wrote:
>> >> > 3. Is C<%MY> intended to reflect the PAD?
>> >>
>> >> Yes.
>> >
>> >Hey! How's this for a scary thought:
>> >
>> > $continuation.the_pad
>>
>> What's that supposed to do, though? You want to alter the pad that
>> gets put in place at the top of the pad list for a continuation? No
>> problem. A bad idea, mind, but no problem... :)
>
>I was thinking it would get the pad of the block from which the
>continuation was taken.
Oh, OK. That makes perfect sense, then, and if you want to write
introspective code I can see it being really useful. I'll try and
make sure you can do it.
Dan Sugalski
>According to Dan Sugalski:
>> One pad per block, rather than per sub.
>
Yep. (Well, modulo optimizations of course ;)
The place where you'll run into problems in where you have multiple
variables of the same name at the same level, which you can do in
perl 5. That's more problematic, and I don't think we're going to
allow that.
Chip Salzenberg
> One pad per block, rather than per sub.
Because, of course, all blocks are subs. Got it.
Chip Salzenberg
> Based on what I rememeber from the long threads about this,
Ouch. I gather, then, that nntp.perl.org does not house complete list
archives, or else the discussion was not on p6-language ... ?
> sub import {
> caller(1).MY{'&foo'} = sub { ... };
> }
Got it.
Dave Mitchell
> According to Dave Mitchell:
> > Based on what I rememeber from the long threads about this,
>
> Ouch. I gather, then, that nntp.perl.org does not house complete list
> archives, or else the discussion was not on p6-language ... ?
don't know about nntp, but see for example,
http://archive.develooper.com/perl6-l...@perl.org/msg08203.html
--
You live and learn (although usually you just live).
Dave Mitchell
> The place where you'll run into problems in where you have multiple
> variables of the same name at the same level, which you can do in
> perl 5.
can it?
can you give an example?
--
In England there is a special word which means the last sunshine
of the summer. That word is "spring".
Dave Mitchell
> At 7:18 PM +0100 7/11/02, Dave Mitchell wrote:
> >On Thu, Jul 11, 2002 at 10:41:20AM -0400, Dan Sugalski wrote:
> >> The place where you'll run into problems in where you have multiple
> >> variables of the same name at the same level, which you can do in
> >> perl 5.
> >
> >can it?
>
>
> >can you give an example?
>
> my $foo = 12;
> print $foo;
> my $foo = "ho";
> print $foo;
> 12ho[localhost:~] dan%
ah, I see what you mean. I hope that'll be a syntax error rather than just
a warning in perl6.
--
"Strange women lying in ponds distributing swords is no basis for a system
of government. Supreme executive power derives from a mandate from the
masses, not from some farcical aquatic ceremony."
Dennis - Monty Python and the Holy Grail.
Dan Sugalski
>> The place where you'll run into problems in where you have multiple
>> variables of the same name at the same level, which you can do in
>> perl 5.
>
>can it?
Yes.
>can you give an example?
[localhost:~] dan% perl
my $foo = 12;
print $foo;
my $foo = "ho";
print $foo;
12ho[localhost:~] dan%
--
Dan Sugalski
>According to Dan Sugalski:
>> At 9:50 PM -0400 7/9/02, Chip Salzenberg wrote:
>> > 3a. If so, how can one distinguish among the e.g. many C<my $foo>
>> > variables declared within the current function?
>>
>> One pad per block, rather than per sub.
>
>
> my $x = 1;
> BEGIN { %MY::{'$y'} = \$x }
> print $y;
>
>So what do I need to make this aliasing work? C<%OUTER::MY::>?
Yup. Or caller, or something. I'm not sure what Larry's planning on
for the syntax.
Dan Sugalski
>On Thu, Jul 11, 2002 at 02:29:08PM -0400, Dan Sugalski wrote:
>> At 7:18 PM +0100 7/11/02, Dave Mitchell wrote:
>> >On Thu, Jul 11, 2002 at 10:41:20AM -0400, Dan Sugalski wrote:
>> >> The place where you'll run into problems in where you have multiple
>> >> variables of the same name at the same level, which you can do in
>> >> perl 5.
>> >
>> >can it?
>>
>> Yes.
>>
>> >can you give an example?
>>
>> [localhost:~] dan% perl
>> my $foo = 12;
>> print $foo;
>> my $foo = "ho";
>> print $foo;
>> 12ho[localhost:~] dan%
>
>ah, I see what you mean. I hope that'll be a syntax error rather than just
>a warning in perl6.
Me too, since it makes pulling lexicals out by name rather tricky.
Doable, but tricky. (And messy, and somewhat expensive) That's
Larry's call, though.
Chip Salzenberg
> At 9:50 PM -0400 7/9/02, Chip Salzenberg wrote:
> > 3a. If so, how can one distinguish among the e.g. many C<my $foo>
> > variables declared within the current function?
>
> One pad per block, rather than per sub.
I just remembered why I thought that woundn't work: BEGIN is a block.
my $x = 1;
BEGIN { %MY::{'$y'} = \$x }
print $y;
So what do I need to make this aliasing work? C<%OUTER::MY::>?
Ashley Winters
> According to Dan Sugalski:
> > At 9:50 PM -0400 7/9/02, Chip Salzenberg wrote:
> > > 3a. If so, how can one distinguish among the e.g. many C<my $foo>
> > > variables declared within the current function?
> >
> > One pad per block, rather than per sub.
>
> I just remembered why I thought that woundn't work: BEGIN is a block.
>
> my $x = 1;
> BEGIN { %MY::{'$y'} = \$x }
> print $y;
Even worse, you should be able to modify lexicals even outside your scope.
sub violate_me {
caller(1).MY{'$y'} := caller(1).MY{'$x'}; # hypothetical syntax
}
{
my $x = 1;
my $y; # Might be able to BEGIN { violate_me() } instead
violate_me();
print $y;
}
Ashley Winters
--
When you do the community's rewrite, try to remember most of us are idiots.
Tim Bunce
> >On Thu, Jul 11, 2002 at 10:41:20AM -0400, Dan Sugalski wrote:
> >> The place where you'll run into problems in where you have multiple
> >> variables of the same name at the same level, which you can do in
> >> perl 5.
> >
> >can it?
>
> Yes.
>
> >can you give an example?
>
> [localhost:~] dan% perl
> my $foo = 12;
> print $foo;
> my $foo = "ho";
> print $foo;
> 12ho[localhost:~] dan%
Of course it's a -w warning now:
"my" variable $foo masks earlier declaration in same scope at - line 3.
and I can imagine it becoming a mandatory warning in later versions
of perl5 (and/or perhaps in future they'll be a way to enable
warnings relevant to migration to perl6).
Tim.
Melvin Smith
>On Thursday 11 July 2002 11:47 am, Chip Salzenberg wrote:
> > According to Dan Sugalski:
> > > At 9:50 PM -0400 7/9/02, Chip Salzenberg wrote:
> > > > 3a. If so, how can one distinguish among the e.g. many C<my $foo>
> > > > variables declared within the current function?
> > >
> > > One pad per block, rather than per sub.
> >
> > I just remembered why I thought that woundn't work: BEGIN is a block.
> >
> > my $x = 1;
> > BEGIN { %MY::{'$y'} = \$x }
> > print $y;
>
>Even worse, you should be able to modify lexicals even outside your scope.
>
>sub violate_me {
> caller(1).MY{'$y'} := caller(1).MY{'$x'}; # hypothetical syntax
>}
>
>{
> my $x = 1;
> my $y; # Might be able to BEGIN { violate_me() } instead
> violate_me();
> print $y;
>}
This reminds me why I don't use Perl4 'local' anymore.
And now we have even uglier ways to write poor code. :)
The only real use I can see of %MY is debugging. If people are going
to take handles to pads and modify lexicals in closures, continuations
and routines from the outside, it probably means that the item needs to
be a class.
And side effects like "I call you, you modify me invisibly...." seems
more like taking dangerous drugs than programming.
Yep, I warned you about calling that routine, now look what it did to
your brains.
-Melvin
Dan Sugalski
>On Thu, Jul 11, 2002 at 02:29:08PM -0400, Dan Sugalski wrote:
>> At 7:18 PM +0100 7/11/02, Dave Mitchell wrote:
>> >On Thu, Jul 11, 2002 at 10:41:20AM -0400, Dan Sugalski wrote:
>> >> The place where you'll run into problems in where you have multiple
>> >> variables of the same name at the same level, which you can do in
>> >> perl 5.
>> >
>> >can it?
>>
>> Yes.
>>
>> >can you give an example?
>>
>> [localhost:~] dan% perl
>> my $foo = 12;
>> print $foo;
>> my $foo = "ho";
>> print $foo;
>> 12ho[localhost:~] dan%
>
>Of course it's a -w warning now:
>
> "my" variable $foo masks earlier declaration in same scope at - line 3.
Yep, that's warned for as long as I can remember, though that isn't
all that long, I suppose. Still, it's valid. Wonder how many people
do that now, completely by accident...
>and I can imagine it becoming a mandatory warning in later versions
>of perl5 (and/or perhaps in future they'll be a way to enable
>warnings relevant to migration to perl6).
I'd hope that it would be one of the things we wouldn't support in
the perl 5 to perl 6 migration tool. Since it's likely always (or
darned close to always) an error, I don't think it'll be a big
problem.
Nicholas Clark
> At 7:35 PM +0100 7/11/02, Dave Mitchell wrote:
> >On Thu, Jul 11, 2002 at 02:29:08PM -0400, Dan Sugalski wrote:
> >> At 7:18 PM +0100 7/11/02, Dave Mitchell wrote:
> >> >On Thu, Jul 11, 2002 at 10:41:20AM -0400, Dan Sugalski wrote:
> >> >> The place where you'll run into problems in where you have multiple
> >> >> variables of the same name at the same level, which you can do in
> >> >> perl 5.
> >> >
> >> >can it?
> >>
> >> Yes.
> >>
> >> >can you give an example?
> >>
> >> [localhost:~] dan% perl
> >> my $foo = 12;
> >> print $foo;
> >> my $foo = "ho";
> >> print $foo;
> >> 12ho[localhost:~] dan%
> >
> >ah, I see what you mean. I hope that'll be a syntax error rather than just
> >a warning in perl6.
>
> Me too, since it makes pulling lexicals out by name rather tricky.
> Doable, but tricky. (And messy, and somewhat expensive) That's
> Larry's call, though.
Is there any specific case where you can't treat
{
my $foo = 12;
print $foo;
my $foo = "ho";
print $foo;
}
as
{
my $foo = 12;
print $foo;
{
my $foo = "ho";
print $foo;
}
}
(where my outer {}s may just be the scope represented by the beginning and end
of the file)
ie implicitly start a new block just before any duplicate my, which continues
until the point the current block ends.
Nicholas Clark
--
Even better than the real thing: http://nms-cgi.sourceforge.net/
Dave Mitchell
> Is there any specific case where you can't treat
>
> {
> my $foo = 12;
> print $foo;
> my $foo = "ho";
> print $foo;
> }
>
> as
>
> {
> my $foo = 12;
> print $foo;
> {
> my $foo = "ho";
> print $foo;
> }
> }
Well, it B*gg*rs up %MY::
The currently planned semantics are:
{
my $x;
exists %MY::{'$x'}; # true;
}
and
{
my $x;
{
exists %MY::{'$x'}; # false
}
}
so consider:
{
my $x;
my $dup;
my $dup;
exists %MY::{'$x'}; # true?
}
which invisibly becomes
{
my $x;
my $dup;
{
my $dup;
exists %MY::{'$x'}; # false?
}
}
--
"But Sidley Park is already a picture, and a most amiable picture too.
The slopes are green and gentle. The trees are companionably grouped at
intervals that show them to advantage. The rill is a serpentine ribbon
unwound from the lake peaceably contained by meadows on which the right
amount of sheep are tastefully arranged." Lady Croom - Arcadia
Dan Sugalski
>On Thu, Jul 11, 2002 at 10:37:27PM +0100, Nicholas Clark wrote:
>> Is there any specific case where you can't treat
>>
>> {
>> my $foo = 12;
>> print $foo;
>> my $foo = "ho";
>> print $foo;
>> }
>>
>> as
>>
>> {
>> my $foo = 12;
>> print $foo;
>> {
>> my $foo = "ho";
>> print $foo;
>> }
>> }
>
>Well, it B*gg*rs up %MY::
True, but if we're only worrying about it for perl 5 code being
translated, it's not a big deal since it won't be using %MY.
Dan Sugalski
>The only real use I can see of %MY is debugging. If people are going
>to take handles to pads and modify lexicals in closures, continuations
>and routines from the outside, it probably means that the item needs to
>be a class.
Yeah, I'm expecting it to be used mainly for introspective things.
It's also useful, at compile time, for changing the caller's
environment, but that's not what we're worried about, I expect.
Richard Clamp
> And side effects like "I call you, you modify me invisibly...." seems
> more like taking dangerous drugs than programming.
>
> Yep, I warned you about calling that routine, now look what it did to
> your brains.
Um, I shouldn't really mention Devel::LexAlias then, since with it you
can already write
caller(1).MY{'$y'} := caller(1).MY{'$x'};
as
lexalias(1, "$y", upto(1, "$x"));
Where upto is would be a simple wrapper around my
Devel::Caller::caller_cv and Robin Houston's PadWalker::peek_sub
No, I'm not waiting till perl6 for the drugs to kick in...
--
Richard Clamp <rich...@unixbeard.net>
Robert Spier
>Ouch. I gather, then, that nntp.perl.org does not house complete list
>archives, or else the discussion was not on p6-language ... ?
It should have complete archives. It uses the same backend data as
the html version on archive.develooper.com.