Related articles |
---|
[7 earlier articles] |
Re: Recursive Descent Parsers and YACC mailrus!sharkey!hela!iti.org!dhw@uunet.UU.NETid AA (1990-11-20) |
Recursive Descent Parsers and YACC grosch@gmdka.uucp (Josef Grosch) (1990-11-22) |
Re: Recursive Descent Parsers and YACC grimlok@hubcap.clemson.edu (1990-11-23) |
Recursive Descent Parsers and YACC jsp@milton.u.washington.edu (Jeff Prothero) (1990-11-23) |
Re: Recursive Descent Parsers and YACC melling@psuvax1.cs.psu.edu (1990-11-26) |
Re: Recursive Descent Parsers and YACC moss@cs.umass.edu (1990-11-26) |
Re: Recursive Descent Parsers and YACC aycock@cpsc.ucalgary.ca (1990-11-26) |
Newsgroups: | comp.compilers |
From: | aycock@cpsc.ucalgary.ca (John Aycock) |
Keywords: | parse, LL(0) |
Organization: | Compilers Central |
Date: | Mon, 26 Nov 90 21:05:22 MST |
| Reply-To: moss@cs.umass.edu (Eliot Moss)
|
| Folks, what is this LL(0) stuff? You need at least one token lookahead to
| choose the correct production in LL or recursive descent parsing, so LL(k)
| makes sense only for k > 0.
Not so. Consider the following grammar:
S -> A B C
A -> a
B -> b
C -> c
No lookahead is required, yet a parser can predict that the first token will
be an 'a', the second a 'b', and so on. As an example of where a grammar like
this could be applied, I recently wrote an EBNF->BNF converter for a compiler
class that took input files of the form:
<file> -> <terminal-section> <nonterminal-section> <start> <rules> .
<terminal-section> -> TERMINALS <terminal-list> END .
<nonterminal-section> -> NONTERMINALS <nonterminal-list> END .
&c...
Admittedly, a rather rigid and restrictive format, but it suited the purpose
nicely.
:ja
--
John D. Aycock aycock@cpsc.ucalgary.ca
(403) 285-8727
[Justin Graver <graver@ufl.edu> send a similar message. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.