From: Klaas-Jan Stol (via RT) <[EMAIL PROTECTED]> Date: Sun, 09 Mar 2008 09:43:02 -0700
# New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #51560] # in the subject line of all future correspondence about this issue. # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=51560 > hi, when running a language in interactive mode, and you declare a local variable, then this local variable cannot be accessed afterwards. . . . Somehow, this makes sense, when looking at the generated PIR. For each input line, a new (anonymous) sub is generated and executed. Any local declarations are local to that sub, and are lost after that point. kjs That's it exactly. A general solution would be: 1. When starting an interactive session, define a "session" sub that uses an expandable LexPad. (I thought Tcl used such a thing routinely, but I can't find it now. In any case, an expandable parrot_context_t might be trickier to arrange.) 2. Extend the compiler to generate ".lex" entries for "No scope found" cases when requested, reporting on any new ones so that the read/eval/print loop can add them to the "session" LexPad. 3. Emit the expression sub as ":outer(session)" so that it uses the common environment. (This requires extending IMCC to support an :outer sub that is already loaded, instead of being in the same compilation unit. I have no clue how hard this would be.) IMHO, this is a lot of trouble for a top-level read/eval/print loop. On the other hand, evaluating HLL expressions in context is a key feature of debuggers, so it will need to be done sooner or later. And it would be nice to solve both problems at once; if you regenerated the outer sub for each new statement and stuffed in the old values from the previous statement, that would be enough for a top-level REPL, but not for a debugger REPL. My $0.02, -- Bob Rogers http://rgrjr.dyndns.org/
