|[6 earlier articles]|
|Re: Why separate Lexical & Parser Generators firstname.lastname@example.org (Walter Smith) (1994-10-10)|
|Re: Why separate Lexical & Parser Generators email@example.com (Charles Fiterman) (1994-10-11)|
|Re: Why separate Lexical & Parser Generators firstname.lastname@example.org (1994-10-11)|
|Re: Why separate Lexical & Parser Generators email@example.com (John Lacey) (1994-10-12)|
|Re: Why separate Lexical & Parser Generators firstname.lastname@example.org (1994-10-14)|
|Re: Why separate Lexical & Parser Generators email@example.com (1994-10-21)|
|Re: Why separate Lexical & Parser Generators firstname.lastname@example.org (1994-10-22)|
|From:||email@example.com (Henry G. Baker)|
|Date:||Sat, 22 Oct 1994 17:30:32 GMT|
John Heron <heronj@smtplink.NGC.COM> writes:
>Pardon me if this question is naive. Why have a separate parser generator
>and lexical analyzer generator? ...
firstname.lastname@example.org (A Johnstone) writes:
>2. Efficiency: recursive descent parsers like the ones generated by
>PCCTS, PRECC, RDP and CoCo tend to do a lot of function calling.
>That's OK at phrase level, but down at the character-by-character
>level a monolithic lump of code is what you need using iteration rather
>than recursion. Anyone who doubts the importance of efficient scanning
>should profile their favorite compiler. You'd be surprised how much of
>the time many compilers spend in the scanner.
Haven't compiler people ever heard of tail call optimizations which
automatically turn recursions of this sort into iterations?
>5. Cleverness on the part of the language designer: anybody looking
>for a really frustrating student project might consider building a
>parser for Occam, in which there are no explicit brackets for compound
>statements but nesting is indicated by indentation.
Cut yourself on Occam's razor, I see. :-)
Read ftp.netcom.com:/pub/hbaker/README for info on ftp-able papers.
Return to the
Search the comp.compilers archives again.