Dan Sugalski wrote:
>
> At 12:11 PM 11/22/00 -0800, Steve Fink wrote:
> >Dan Sugalski wrote:
> > >
> > > 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...)
Oh, sorry. I didn't mean the invalidation for support of versions. I
meant on-the-fly parser changes. use new_infix_operator ['sgt',
['perl',\&sorta_greater_than],
['C','sorta_greater_than',['int','int'],'int']];
Hm. Bad example. That sounds like something that would be much better
off as a lookup table. Ok, here's a more concrete example: the LALR
parser generator I wrote (Parse::YALALR) has vestigial support for
conditional reductions. As in, here's the grammar, but only perform this
reduction if eg you're expecting to see an operator or if the user says
the precedence of this token is more than that of '='. Perhaps something
like that could be parlayed into a usefully flexible parser, where those
conditional tests start out in C code but can be overridden with Perl.
And that Perl can be optimized by converting it to C and compiling it
and linking it back in a la Inline.pm.
But this is internal API fodder. Or something.
