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
