there's no undef!
Michal Wallace
Uh-oh. I just went to implement "del x"
and there's no op to remove a variable
from a lexical pad! :)
Sincerely,
Michal J Wallace
Sabren Enterprises, Inc.
-------------------------------------
contact: mic...@sabren.com
hosting: http://www.cornerhost.com/
my site: http://www.withoutane.com/
--------------------------------------
Leopold Toetsch
> Uh-oh. I just went to implement "del x"
> and there's no op to remove a variable
> from a lexical pad! :)
new_pad P0
...
delete P0["foo"]
This needs delete_keyed() in scratchpad.pmc to be implemented.
> Sincerely,
>
> Michal J Wallace
leo
Leopold Toetsch
> Michal Wallace <mic...@sabren.com> wrote:
>
>
>>Uh-oh. I just went to implement "del x"
>>and there's no op to remove a variable
>
> This needs delete_keyed() in scratchpad.pmc to be implemented.
I have put in scratchpad_delete
peek_pad P0
delete P0["foo"]
deletes names only.
leo
Michal Wallace
> I have put in scratchpad_delete
>
> peek_pad P0
> delete P0["foo"]
>
> deletes names only.
Thanks! works great!
Benjamin Goldberg
Michal Wallace wrote:
>
> Uh-oh. I just went to implement "del x"
> and there's no op to remove a variable
> from a lexical pad! :)
Why would you want to remove a variable from a lexical pad?
Surely the "right thing to do" would be to create a new pad (scope),
then add your 'x' variable which you plan to 'delete' in the future,
then when you want to delete that variable, pop off that pad.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
Michal Wallace
> Michal Wallace wrote:
>
> > Uh-oh. I just went to implement "del x"
> > and there's no op to remove a variable
> > from a lexical pad! :)
>
> Why would you want to remove a variable from a lexical pad?
>
> Surely the "right thing to do" would be to create a new pad (scope),
> then add your 'x' variable which you plan to 'delete' in the future,
> then when you want to delete that variable, pop off that pad.
Hmm. Do you mean
if for stmt in block:
if stmt.type == undef:
flag_as_going_to_delet(stmt.varname)
So I can create a new pad when it's assigned?
It can't be a simple pop though, can it?
#!/usr/bin/perl
$x = "cat";
$y = "pop $x?";
undef $x;
print "x = $x \n";
print "y = $y \n";
Because here, $x has to be defined before $y, so
I'd have to delete the -2nd scope. Unless the
code was smart enough to work out that y is in
-2 and x is in -1...
In any case, what does it buy me? it seems like a
lot of work when there's already a delete_keyed
op, and leo just made an implementation for pads. :)
I guess in perl it's not bad, since that's the
whole point of undef, you can just $x = PerlUndef
it... But in python, this throws a NameError:
x = 1
del x
x
So the easiest thing to me is just to translate
del x as "remove this from the current pad".
Benjamin Goldberg
Michal Wallace wrote:
>
> On Sun, 17 Aug 2003, Benjamin Goldberg wrote:
>
> > Michal Wallace wrote:
> >
> > > Uh-oh. I just went to implement "del x"
> > > and there's no op to remove a variable
> > > from a lexical pad! :)
> >
> > Why would you want to remove a variable from a lexical pad?
> >
> > Surely the "right thing to do" would be to create a new pad (scope),
> > then add your 'x' variable which you plan to 'delete' in the future,
> > then when you want to delete that variable, pop off that pad.
>
> Hmm. Do you mean
>
> if for stmt in block:
> if stmt.type == undef:
> flag_as_going_to_delet(stmt.varname)
>
> So I can create a new pad when it's assigned?
Right. You'd create a new pad just before the "for", and put "stmt"
into it. After the for loop ends, you pop off that pad.
> It can't be a simple pop though, can it?
Why not?
> #!/usr/bin/perl
> $x = "cat";
> $y = "pop $x?";
> undef $x;
> print "x = $x \n";
> print "y = $y \n";
>
> Because here, $x has to be defined before $y, so
> I'd have to delete the -2nd scope. Unless the
> code was smart enough to work out that y is in
> -2 and x is in -1...
These are dynamic variables here; could you give an example of what
you're trying to do with lexicals (my variables)? And remember, undef
doesn't get rid of a variable; it merely stores an undef value into it.
I mean, consider:
#!/usr/bin/perl
use strict;
{ my $x = "cat";
{ my $y = "pop $x";
# $x and $y are both in scope.
undef $x;
# $x and $y are still both in scope.
$x = 2; # no error here!
} # $y goes out of scope.
$x = 42; # ok.
$y = 6*9; # but this is an error.
} # $x goes out of scope now.
$x = 13; # this is an error.
__END__
There's no way, in this program, for $x to be out of scope while $y is
in scope.
> In any case, what does it buy me? it seems like a
> lot of work when there's already a delete_keyed
> op, and leo just made an implementation for pads. :)
>
> I guess in perl it's not bad, since that's the
> whole point of undef, you can just $x = PerlUndef
> it... But in python, this throws a NameError:
>
> x = 1
> del x
> x
>
> So the easiest thing to me is just to translate
> del x as "remove this from the current pad".
Maybe. But, what happens with:
x = 1
y = lambda: x
del x
z = y()
Does/should this also throw a NameError?
Michal Wallace
> > Hmm. Do you mean
> >
> > if for stmt in block:
> > if stmt.type == undef:
> > flag_as_going_to_delet(stmt.varname)
> >
> > So I can create a new pad when it's assigned?
>
> Right. You'd create a new pad just before the "for", and put "stmt"
> into it. After the for loop ends, you pop off that pad.
> > It can't be a simple pop though, can it?
>
> Why not?
Because in my examples, I don't see how you know
it's the topmost lexical pad.
> These are dynamic variables here; could you give an example of what
> you're trying to do with lexicals (my variables)?
Sure.
It does the exact same thing if you put "my" in front of each variable:
#!/usr/bin/perl
my $x = "cat";
my $y = "pop $x?";
undef $x;
print "x = $x \n";
print "y = $y \n";
> And remember, undef doesn't get rid of a variable; it merely stores
> an undef value into it.
But it has the same effect as getting rid of the variable,
since a variable that doesn't exist also returns undef. :)
> I mean, consider:
>
> #!/usr/bin/perl
> use strict;
> { my $x = "cat";
> { my $y = "pop $x";
> # $x and $y are both in scope.
> undef $x;
> # $x and $y are still both in scope.
> $x = 2; # no error here!
> } # $y goes out of scope.
> $x = 42; # ok.
> $y = 6*9; # but this is an error.
> } # $x goes out of scope now.
> $x = 13; # this is an error.
> __END__
>
> There's no way, in this program, for $x to be out of scope while $y is
> in scope.
Yes, but this is just normal lexical scoping behavior.
I'm already doing the same thing for python.
You say that in perl, undef $x means $x = PerlUndef, which
is fine. But in python, that's not the case. "del x" gets
rid of the variable, so that the next find_lex should throw
a NameError. I don't see the point in creating an extra
lexical scope for every variable that gets deleted.
And that's not what you're telling me anyway.
In your innermost block, you're telling me that on the
python equivalent of the "undef $x" line i should be
popping off a lexical pad in python. I'm saying
that's not the case. I should be removing x from the
lexical pad. If perl does the same thing, then you
get the same behavior as undef x, because an unfound
lexical in perl just returns PerlUndef anyway.
> > x = 1
> > del x
> > x
> >
> > So the easiest thing to me is just to translate
> > del x as "remove this from the current pad".
>
> Maybe. But, what happens with:
>
> x = 1
> y = lambda: x
> del x
> z = y()
>
> Does/should this also throw a NameError?
Looks like it:
>>> x = 1
>>> y = lambda : x
>>> del x
>>> z = y()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 1, in <lambda>
NameError: global name 'x' is not defined
Anyway, the short answer is I'm happy with the
solution I've got now. It's easy and it does
what I expect. But I'll happily change it if
you send me a patch. :)
Sean O'Rourke
> There's no way, in this program, for $x to be out of scope while $y is
> in scope.
But we're in Perl6(66)-land, where "delete caller.MY{'$x'}" and
"delete %OUTER::x" (sp?) can wreak havoc on your pad from all
sorts of strange places. It ain't moral, but it sure is legal.
/s
Leopold Toetsch
> Maybe. But, what happens with:
> x = 1
> y = lambda: x
> del x
> z = y()
> Does/should this also throw a NameError?
Yep. It throws a NameError. So deleting from the lex pad is ok.
leo