On Fri, 22 Dec 2000, Dan Sugalski wrote:
> 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.
Is it safe to assume there will be a mechanism for "compiled" Perl programs
to be stored as executables with bytecode? (On Unix, this could use a #!
line for perl with appropriate switches... Or will it auto-recognize the
bytecode? Will it be possible to intermix bytecode with normal code a la
emacs-lisp?)
> >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)
Why not go the other direction? Why not write everything in Perl first by
preference (maybe even the runtime part) and reimplement parts in C only as
necessary for performance reasons? It could get working code sooner, avoid
unnecessary C coding where Perl is "fast enough" (perhaps unexpectedly),
and provide a reference implementation as a guide for the C implementation.
(Hey, even the regex engine doesn't necessarily need to be entirely in C;
maybe the compiler half would work well enough in Perl?)
Except for obvious performance-critical bottleneck areas, what advantages
are there to implementing anything else first in C?
Deven
