On Sat, Jun 24, 2006 at 08:03:47AM -0700, Audrey Tang wrote:
> 2006/6/24, Nicholas Clark <[EMAIL PROTECTED]>:
> >Is Parrot assembler considered a more productive language to write in than
> >C?
> >If yes, is it logical to write opcodes such as this one in Parrot assembler
> >itself?
>
> Err, well, that will likely completely kill the performance. :-)
>
> I had an implementation before Parrot had lexical pads, using global
> variables and manual walking to emulate it. It was horribly slow.
> Especially consider that Pugs currently compiles:
>
> my $x; sub f { say $x; ...
>
> to
>
> my $x; sub f { say $OUTER::x; ...
>
> because later in the scope $x may be declared, so it's safer to just
> put OUTER right there.
I don't think $x can be declared later in the scope. According to S04,
If you've referred to $x prior to the first declaration,
and the compiler tentatively bound it to $OUTER::x,
then it's an error to declare it, and the compiler is
allowed to complain at that point.
The Perl 6/Parrot compiler is simply using the find_lex opcode,
which of course does the outer lookups directly. OUTER comes into
play only when we need to explicitly exclude the current lexical
scope from the lookup.
> Of course, if we cannot have an efficient OUTER lookup, we can always
> do a post analysis on the block body and convert unneccessary OUTER::
> away, but I don't think it's a good idea to force compile writers to
> do that.
Part of me wonders if OUTER occurs frequently enough that it
needs a C-based opcode. However, given that we have at least
two languages (Perl 6 and Tcl) that are indicating they need
to be able to do OUTER lookups, it may deserve an opcode.
Pm
