Dan Sugalski wrote:
>
> You're not wrong, but I don't think this is a huge problem. Lots of systems
> do it like this at the moment--GCC comes to mind as a first one, but there
> are lots of others. Granted it does mean that we'll need to ship a
> bytecode-compiled version of the parser as part of the perl distribution,
> but that's not a big deal. (Besides, that's what Larry wants, and he's got
> a point)
>
> It's also possible we'll do the parser mainly in C with perl hooks, but
> that's not the direction I've been pointed in.
Write it entirely in perl, but have native C implementations of all the
time-critical subroutines. Use the C stuff by default, but have an
invalidation bit in case the perl version changes. And when everything's
working, allow compiling the perl subroutines individually into machine
code for medium-speed variants that can also be invalidated.
Just an idea. May not work out in practice, because it's often the
plumbing between the subroutines that sucks up all the time.