On Sat, 2002-09-07 at 10:53, Sean O'Rourke wrote:
> On Sat, 7 Sep 2002, Chuck Kulchar wrote:
> > Also, how do these perl6 builtins in perl6 work with the current
> > P6C/Builtins.pm? (also, why are some that are already defined in pure
> > pasm/part of the parrot core redefined as perl6 code?)
>
> For the moment, "they don't". Eventually, I expect there will be some
> sort of a "header file" with the builtin declarations (P6C parses and
> interprets function declarations for this very reason), and a .pbc file
> containing their code. As for why they're written in perl 6 code, I
> expect it's easier to define their semantics in Perl than in assembly.
Correct in as far as it goes. The more general answer is that one of the
goals of this re-write (as I was lead to believe) was that the Perl
internals would be maintainable. If we write the well over 150 Perl 5
builtins in Parrot assembly, I think we can kiss that wish goodbye.
Some of this will have to be done in assembly, but hopefully a very
small and modular core (e.g. my proposal earlier on how to handle pack,
sprintf and chr). The rest will be the subject of increasingly powerful
optimizations that the compiler will have to perform for user code
anyway. Ultimately I would hope that the only builtins that will be
represented 100% in assembly will be those that have a 1-to-1 mapping in
the parrot instruction set (e.g. scalar).
BTW: Current status is that I'm preparing to make some changes to the
compiler tonight. After that, I'll be ready to issue a patch against the
current tree. Over the weekend I focused on getting all of the builtins
to compile cleanly and I implemented a few other small pieces. We now
have a sprintf that can handle C<'%d'> and C<'%s'> along with some
simple modifiers, so C<printf("%02d%% of % 6s\n")> should work.
I'm making heavy use of C<given>, in the assumption that it will make
the code easy to optimize.
--
Aaron Sherman <[EMAIL PROTECTED]>
http://www.ajs.com/~ajs
