Re: Eval doesn't see lexicals

You need to include more details or we can only guess at what is meant.

Here is an example of a guess.

sub will_not_be_a_closure {
  my %serial_of = @_;
  return sub {
    eval 'use Data::Dumper; print Dumper \%serial_of;';
  }
}

will_not_be_a_closure(foo=>"bar")->();
[download]

The problem is that when will_not_be_a_closure exits, Perl sees no references to %serial_of and so cleans it up. This is known behaviour and the last I heard it is unlikely to change.

The solution is to use that variable in any trivial way in the subroutine so that you still have a reference to it. If you use all of the variables that you might use in trivial ways, they will all be there and the eval will find the ones that you want. Like this:

sub will_be_a_closure {
  my %serial_of = @_;
  return sub {
    my $x = $serial_of{x};
    eval 'use Data::Dumper; print Dumper \%serial_of;';
  }
}

will_be_a_closure(foo=>"bar")->();
[download]

Note that in general if you need to use closures and eval, it is better to try to use eval to generate closures rather than to call eval from within a closure. (I know, there are plenty of cases where you can't feasibly do this. But if you can...)

Two random tips on eval. First, it is good when you use eval to be in the habit of always checking $@ afterwards. Even for trivial evals. Secondly go to the very bottom of perlsyn and read about Plain Old Comments (Not!) and use that change the usual (eval 666) in error messages into something useful (or at least greppable in your source to find the source of the failing eval).

Comment on Re: Eval doesn't see lexicals Select or Download Code

Replies are listed 'Best First'.
Re^2: Eval doesn't see lexicals by Anonymous Monk on Nov 02, 2005 at 02:43 UTC
Okay, I think I understand. Variables that perl doesn't see being used get cleaned up when going out of scope. The variables go out of scope when the end of the file is reached which is why the code malfunctions when in a separate file.</> I take it that variables still hang around at the start of a new package even though they are no longer directly acessible ( I am supposing that putting { and } around the entire package would change this, at least the samples for Class::Std do it, and there would have to be a reason.) It makes sense, but it's pretty obscure ... thanks to all for your input.	[reply]
Re^3: Eval doesn't see lexicals by tilly (Archbishop) on Nov 02, 2005 at 02:53 UTC
Mostly right. The quibble is that I strongly suspect some confusion about how lexical scope works. Coping with Scoping may clarify that. In short, a package declaration affects global variables, not lexical. So lexical variables in scope remain in scope across the package declaration. Like this: `my $foo = "bar"; package Baz; print "$foo\n"; # prints bar` [download] Hence the braces as done in the examples for Class::Std serve the purpose of making lexical scope match package scope. Which is important when you're going to want separate lexical variables with the same name.	[reply] [d/l]
Re^3: Eval doesn't see lexicals by dave_the_m (Monsignor) on Nov 02, 2005 at 10:39 UTC
I take it that variables still hang around at the start of a new package even though they are no longer directly acessible ( I am supposing that putting { and } around the entire package would change this, at least the samples for Class::Std do it, and there would have to be a reason.) No, source code files are already treated as if they were surrounded by { and }, and variables are normally freed at the end of executing the included file. If a sub in that file captures the variable, then its lifetime is extended, but only that sub can subsequently access the retained value. For example: `# Foo.pm my $var = 1; sub a { eval '$var' # sees an undefined value when later called } sub b { $var; eval '$var'; # sees 1 because b() has captured $var }` [download] Note that the variable's lifetime is extended merely by the existence of b(), but even with the existence of b(), a() cannot see the variable. Dave.	[reply] [d/l]