At 12:11 PM 11/22/00 -0800, Steve Fink wrote:
>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.
Dunno if we'll go that far--I think things'll change infrequently enough
that we can hand-sync things when we release a new dev version. But C
versions of things that need to be faster than perl are definitely an
option, if it turns out that the parser is slow enough for this to be an
issue. (And part of our job will be to see that it isn't, since it'll mean
perl will be faster in general...)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
