Re^4: Indirect variable name

Hi Moritz

> Symbolic deferences only look in the symbol table, not in the lexical pad. A reason for that is that lexical variables can be removed from an outer pad when taking a closure, and allowing symbolic differentiation would defeat that optimization.

sorry I don't understand this argumentation, if you want to make a symderef on a lexical you can always use eval. The optimization shouldn't be bothered about this possibility.

our $x=666; #develish

{
    my $x='et voila';
    my $y="x";
    print eval "\$$y"; # prints "et voila"
}
[download]

If ever it fails because of optimization, it's in the responsibility of the hacker, like eval is.

so why shouldn't there be a symderef for lexicals, that actually does an eval???

the reason why perl 5 can't do this out of the box, is IMHO most probably that lexicals were too new to consider all use-cases...

Cheers LanX

Comment on Re^4: Indirect variable name Download Code

Replies are listed 'Best First'.
Re^5: Indirect variable name by moritz (Cardinal) on Nov 21, 2008 at 07:18 UTC
sorry I don't understand this argumentation, if you want to make a symderef on a lexical you can always use eval Not if a closure didn't include that variable: `use strict; use warnings; my $sub = do { my $x = 4; my $y = 5; sub { my $a = shift; print 'Accessing $x: ', $x + $a, "\n"; print 'Accessing $y from eval: ', eval '$y + $a', "\n"; }; }; $sub->(2); __END__ Accessing $x: 6 Use of uninitialized value in addition (+) at (eval 1) line 1. Accessing $y from eval: 2` [download] Whoops. Perl knows at compile time which lexicals in outer scopes are needed for a closure, and only stores those. With the current current behaviour only eval can be used to detect that. That's OK because eval has the "evil, don't use" stigma on it. If symbolic deref would also look in lexicals, every deref might break this optimization. I hope it's a bit clearer now.	[reply] [d/l]
Re^6: Indirect variable name by LanX (Saint) on Nov 21, 2008 at 10:01 UTC
Thanks, but > That's OK because eval has the "evil, don't use" stigma on it. Well which is perfectly the same with symderef, that's why it's not strict! When the code breaks, the compiler can't be blamed. No optimization would be hindered by that. Cheers Rolf	[reply]
Re^7: Indirect variable name by moritz (Cardinal) on Nov 21, 2008 at 10:35 UTC
Well which is perfectly the same with symderef, that's why it's not strict! symbolic derefs are not syntactically distinguished from "normal" derefs, so I do see a difference to the case with eval.	[reply]
Re^8: Indirect variable name by LanX (Saint) on Nov 21, 2008 at 10:58 UTC
Re^9: Indirect variable name by LanX (Saint) on Nov 21, 2008 at 11:20 UTC


Welcome to the Monastery
	PerlMonks