Ticket #1198 (closed bug: fixed)

Opened 5 years ago

Last modified 3 years ago

interactive mode doesn't save lexicals correctly

Reported by: kjs Owned by: pmichaud
Priority: normal Milestone:
Component: PCT Version:
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:



when running a language in interactive mode, and you declare a local variable, then this local variable cannot be accessed afterwards.

This is true for perl 6 as well:

my $var = 1;

say $var; No scope found for PAST::Var '$var'

Maybe for Perl 6 this is ok, but many other languages, such as Lua and Python, this should work.

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.


Change History

Changed 5 years ago by coke

Changed 5 years ago by coke

Comment by Bob Rogers:

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/

Changed 5 years ago by coke

Comment from pmichaud:

Just adding my nickel that I agree with Bob on this point -- it's a lot of trouble at the moment which is why we haven't done much about it yet. I'm expecting that at some point we'll tweak PCT (and possibly Parrot's) handling of lexical variables, and we can potentialy revisit it then.

In particular, we may need the capability for a sub to poke new entries into another (caller's) LexPad.

Changed 4 years ago by coke

I know this was resolved for Rakudo -- Were the fixes done for Rakudo generally applicable to any HLL using the REPL?

Changed 3 years ago by pmichaud

  • status changed from new to closed
  • resolution set to fixed

This is now fixed for all HLLs that are using the REPL in HLL::Compiler in nqp-rx (and that emit the appropriate setup code in their compiled output). Marking ticket as 'fixed'.


Note: See TracTickets for help on using tickets.