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.

Reply via email to