On Wed, Sep 24, 2008 at 10:05:25PM +0200, Stéphane Payrard wrote: > One of parrot current limitation is that eval is always a closure. > When using rakudo interactively, one want to introduce new > lexical variable that are not lost when accessing them from the > next prompt. > Pugs gets that right.
I would like to make sure we distinguish 'eval' from 'interactive prompt' -- they're probably not the same. AFAICT while Perl 6's C<eval> function is able to access lexical variables in the scope where it is used, it's not necessarily able to create new ones in that scope. In other words: { eval 'my $x = 4' say $x; # compile-time failure, $x doesn't exist } { eval 'my $x = 4'; eval 'say $x'; # run-time failure, $x doesn't exist } I think this is most consistent with the statements in S02:1780, that seem to indicate that lexical symbol tables are currently fixed at compile time: You may not use any lexically scoped symbol table, either by name or by reference, to add symbols to a lexical scope that is done compiling. (We reserve the right to relax this if it turns out to be useful though.) So, in order to get the behavior you're describing from the interactive prompt, we'll probably need more than just Perl 6's 'eval'. In particular, the interactive prompt mode will need to be able to maintain it's own dynamic lexical pad (i.e., a DynLexPad) and have some way of extracting any lexical changes from whatever code string it evaluates. At any rate, even though I don't discuss DynLexPad's in the new design, I'm confident that it will be far easier to accommodate and use them than the one that exists now, and to be able to achieve the 'interactive mode' semantics you've described above. Pm