Related articles |
---|
[3 earlier articles] |
Re: Buffered input for a lexer? sabre@nondot.org (Chris Lattner) (2002-03-24) |
Re: Buffered input for a lexer? sabre@nondot.org (Chris Lattner) (2002-03-24) |
Re: Buffered input for a lexer? rhyde@cs.ucr.edu (Randall Hyde) (2002-03-25) |
Re: Buffered input for a lexer? cfc@world.std.com (Chris F Clark) (2002-03-25) |
Re: Buffered input for a lexer? clint@0lsen.net (2002-03-31) |
Re: Buffered input for a lexer? sabre@nondot.org (Chris Lattner) (2002-03-31) |
Re: Buffered input for a lexer? sabre@nondot.org (Chris Lattner) (2002-03-31) |
Re: Buffered input for a lexer? joachim_d@gmx.de (Joachim Durchholz) (2002-03-31) |
Re: Buffered input for a lexer? cgweav@aol.com (2002-03-31) |
Re: Buffered input for a lexer? bear@sonic.net (Ray Dillinger) (2002-04-10) |
Re: Buffered input for a lexer? bear@sonic.net (Ray Dillinger) (2002-04-10) |
Re: Buffered input for a lexer? cgweav@aol.com (2002-04-13) |
Re: Buffered input for a lexer? ralph@inputplus.co.uk (2002-04-16) |
[8 later articles] |
From: | Chris Lattner <sabre@nondot.org> |
Newsgroups: | comp.compilers |
Date: | 31 Mar 2002 23:20:09 -0500 |
Organization: | University of Illinois at Urbana-Champaign |
References: | 02-03-162 02-03-172 |
Keywords: | lex, practice |
Posted-Date: | 31 Mar 2002 23:20:09 EST |
Chris F Clark <cfc@world.std.com> wrote:
> The performance impact of a push v. a pull style lexer is negligible.
> It is below the threshold of what we've been able to ever measure. We
I definitely believe that.
> The one notable exception to that are the people using our system to
> do real event-driven state machine models. They need the push model
> and do some very interesting things with it. The push models combines
> very well with objects to make little machines that you can
> run/pause/save/restore/resume/.... all in parallel.
Interesting. How does the lookahead of the lexer and parser interact
with the push style of input? Did you have to change the parsing
algorithms to perform reductions as soon as possible?
Does your customer use your yacc++ grammar file to define the state
machine, or do they use something closer to a state machine description
language? It seems that describing a state machine with a grammar would
be kind of odd (although I haven't tried. :)
> More important are the details of the implementation. Those places
> where our code is even subtly different than [f]lex and yacc/bison can
> cause various hacks that people have developed over the years to fail.
Unfortunately, backwards compatibility is always an impediment to
progress. I imaging with lex and yacc that one of the big problems is
"undocumented" interfaces that people use, not to mention the more or
less hackish nature of the documented interfaces provided...
Thanks for the insight!
-Chris
Return to the
comp.compilers page.
Search the
comp.compilers archives again.