Re: Non-definition of lexical referenced in string eval

I raised this in my very first post 541345, and never really got a satisfactory explanation of the behaviour. However, there is (almost) always a better way to do it than eval.

Comment on Re: Non-definition of lexical referenced in string eval

Replies are listed 'Best First'.
Re^2: Non-definition of lexical referenced in string eval by AnomalousMonk (Archbishop) on Dec 16, 2008 at 15:32 UTC
You know, I thought I remembered some sort of discussion of a similar topic somewhere, but I just couldn't reference it! The reply Re^3: eval a reference to a my hash by chromatic seems to provide some explanation, but I still can't understand why, if the lexical "[doesn't] really have [a name] anymore", the variable is still in scope and accessible by name, but just undefined.	[reply]
Re^3: Non-definition of lexical referenced in string eval by chromatic (Archbishop) on Dec 16, 2008 at 17:30 UTC
Lexical names get translated into indexed accesses into lexical pads at compile time. For a metaphor, imagine that the compiler keeps a hash translating `$lexname` to `$lex_id`. When a doubly-nested eval runs at runtime, the name doesn't really exist anymore.	[reply] [d/l] [select]