On Wed, Sep 24, 2008 at 11:31 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> 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
>
There is two kind evals in Perl 5 that are both closures.
We could have 3 kinds in Perl6 a
-the closure eval : { .... some code }
it is a closure, it is is compiled at compile time. The braces
emphasize the existence of a closure.
-the porous eval : ' ... some code '
It uses a quoting mechanism which content is evaluated
at compile time. The eval is not a closure, lexical variables are
created in the scope where the eval belongs.
Porous eval could be an error because it does not
provide anything that could not be done by simply inlining in
the surrounding code the code from the eval.
Except if we add a special restriction that the porous eval cannot
declare a variable (lexical or not) that is already visible. That
means we could use the porous eval as a way to drop code
without the unexpected consequence of shadowing variable to the
code that follows the eval. This may address a concern that may
have motivated the statements in S02:1780.
-the dynamic eval : "... some code " or " { ... some code }"
it uses a quoting mechanism which content is evaluated at
execution time.
It is not a closure so if we want one we write explicitely the closure
by surrounding the code with braces :
"{ ... some code }"
So, to sum up, there is two things to consider :
-the time of compilation of the eval
-the existence of a closure or not.
This makes four cases covered by my three kind of evals.
The porous eval case can be dropped if the shadowing restriction is
not adopted.
Dynamic eval is not safe, so one could argue that we need two
different names for operators that have two different behaviors.
Concerning dynamic scopes, the eval with closure does not bring
any special semantic.
Note: I mentionned I had talked about the subject eight years ago
but apparently forgot to mention the URL :
http://dev.perl.org/perl6/rfc/351.html
My current proposal addresses the same problem but is different.
--
cognominal stef
