At 02:43 PM 12/22/00 -0500, Deven T. Corzine wrote:
>I don't know if this has been discussed before, but I'm just tossing this
>idea on the table for discussion and consideration. (If this was already
>discussed, please tell me what the conclusion was, if any.)
>
>How about implementing the Perl 6 compiler in Perl 6 itself?
The bits of perl 6 that are going to be written in perl will eventually be
bytecode compiled by perl 6. When exactly this happens is currently up in
the air, though it's something we'll certainly need to do before releasing
perl 6.
>Note that I'm _not_ talking about the runtime environment needed to execute
>Perl code, but the compiler code that parses the Perl source and generates
>bytecode, syntax trees, C code, or whatever else. If we take an analogy to
>Java, there could be a "Perl Virtual Machine" (for lack of a better term)
>providing the runtime environment -- the "PVM" would be written in portable
>C code, but the Perl compiler could be in Perl.
Well, some of it certainly will, and one of the goals is to be able to
extend those bits of perl that were either unextendable or doable in C only
with both perl and C.
Speed of the executable is definitely an issue, as is speed in writing.
While I expect perl 6 to be faster than perl 5, it'll still be slower than
C for a number of things. What we'll likely see is the less intensive bits
(the parser, say) written mostly in perl, with the rest (bytecode compiler,
optimizer, and runtime) in C to start. More of that'll be perl as time goes
on, not with perl replacing C but with the new bits written in perl because
it's faster to do so. (And probably rewritten in C as they turn out to be
bottlenecks)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
