Steve Fink wrote: > > I suspect a slight variant of the above may work best. Rather than > doing a full-out LALR(1) parser for the bottom-up components, you'd do > a somewhat more naive but still table-driven (shift/reduce) parser, > carefully limiting what it is assuming about the FIRST() etc. of the > rules within it. That should limit the impact of changes, and simplify > the logic of what needs to be done differently when a change is > detected.
It's the best alternative I've heard so far. If anyone had the time, skills, and interest, I'd be inclined to set them on it. Even if the results didn't end up meeting our needs for Perl 6, they'd be useful for other HLLs. > Optimization hints could also be very helpful, or we could even > default to a total recursive-descent parser and only attempt bottom-up > precomputation if the grammar author specifically says it's ok. The > main problem being that people will say lots of things if it makes > their code faster, without having any idea what it actually means. In which case, they get exactly what they deserve. :) Allison
