Talk:Recursive descent parser

message: This page really needs a discussion of the problem of left-recursive grammar rules.  Such rules are extremely common, as for example
	EXPR = INT | EXPR + EXPR | EXPR * EXPR;
A recursive descent parser, presented with this grammar, will loop forever on a malformed input.
Should probably mention that hand-written recursive descent parsers are usually based on EBNF grammars?  These support left-recursion by turning
     A = A b C | C
into
     A = C (b C)*
Paolo Bonzini, 09:34, 8 Mar 2006 (UTC)
thread_title: Untitled

message: Does not look like it accepts this: 
//                     ident :=      number   *    -   number   .   
:Correct.
Symbol symbols[7] = {ident,becomes,number,times,minus,number,period}; 
Should it?
: The parser is based on the [PL/0] grammar (a compiler used in many compiler construction courses), which is in turn based on Pascal.  For reasons unknown to me, standard Pascal does not allow imbedded unary expressions.  For instance:
ident := -ident * number;
:is allowed, however, expressions such as yours are not.
:To allow this, you could add "-|+" to the factor production, as in:
factor = 
         ident 
       | ("+"|"-") factor
       | number 
       | "(" expression ")"
:And change the parser appropriately. 
:Since the [PL/0] grammar is so well known, I'm of the opinion that the grammar should be left as  is. 68.219.72.181 13:47, 17 April 2006 (UTC)
thread_title:  Does it accept 1*-1? I'm not sure it does 

message: There is a new See Also entry that I have a question about.
It points to a 'source code' site (nothing wrong with that), but it doesn't seem to add very much.  It is essentially the example, copied from this wikipedia site (without any notice of the copying, by the way), plus another simple example.
Should this link be deleted?  67.34.42.125 12:27, 22 May 2006 (UTC)
thread_title:  Question about See Also entry 

message: Before returning, expect() emits an error internally if necessary. No client of expect() tests the function's error result; ignoring it is legal but dubious practise which detracts from clarity in example code. The function's type should be void not int.  — Preceding unsigned comment added by 203.211.96.228 (talk) 00:01, 3 March 2021 (UTC)
thread_title:  expect() in C implementation 

message: I have removed references to parsing expression grammars in this discussion on recursive descent parsing, as the content referring to PEGs, at least as formulated, tended to give the impression that PEGs are a widely adopted formalism. Parsing expression grammars, while analytic, are a formal grammar, and RD parsing is a parsing strategy (algorithm). QTJ 04:36, 11 October 2006 (UTC)
thread_title:  PEGs 

message: The code inside block(), after "while (accept(procsym))" seems to be nonsense, right?
There are 2 nested while-loops and as far as i understand the grammar only the outer one
should be there. Catskineater (talk) 17:28, 30 March 2008 (UTC)
thread_title:  Bug in the parser code 

message: I just wrote one of these in SML for an assignment. Should I post it here under Implementation in functional languages? bkhl (talk) 07:47, 13 May 2008 (UTC)
thread_title:  SML example 

message: The "recursive descent with backup" discussion, while correct, troubles me.  "X with backup", for any parsing algorithm X, will parse any context-free language.  It will do so, except in a very few cases, at the expense of every virtue which the original algorithm X had.
Perhaps the "backup" discussion might be moved later in the article.  I'd almost suggest deleting it, but the topic does come up.  Almost automatically, whenever algorithm X proves inadequate, backup will be suggested.  Quite often, it will be tried.  My wishing it were not so, does not help.  So some kind of discussion of "backup" as an alternative probably needs to be kept.
--Jeffreykegler (talk) 03:23, 26 May 2010 (UTC)
thread_title:  Recursive descent with backup 

message: The example uses no token look ahead at all and thus is not really helpful to understand the strength of recursive descent parsers. There should at least be a bit of ambiguity in the grammar, otherwise the example is too trivial and - even worse - points the reader into wrong directions.  — Preceding unsigned comment added by 139.30.5.126 (talk) 18:33, 27 March 2012 (UTC)
thread_title:  Expansion necessary 

message: Sorry to nag, but this article doesn't provide an answer to the simple question of what a Recursive descent parser is. I'm sure that the information is technically correct in a formal way, but an encyclopedia article really should provide some understanding of the subject to an interested reader. I suspect the authors are very talented people that are communicating among themselves, but to the average person this is gobbledygook. I've been programming since 1972, know FORTRAN, Pascal, C, assembly languages for the PDP-8, CDC 6400 and 6600, 8080 and 8086 Intel chips, Python, APL, PHP, and probably a few others, and I don't know what a recursive descent parser is after reading this article. If I'm lost, many others are also going to be left bewildered by the article. Kd4ttc (talk) 04:54, 22 November 2012 (UTC)
thread_title:  The article doesn't explain what a Recursive descent parser is 

message: The grammar rules suggest that the following string should be accepted by this grammar:
begin foo := 5 ; end
i.e. The grammar rules accepts (in fact, requires) a semicolon between the "5" number token and the "end" endsym token whereas the implementation of the relative portion of the "statement" function looks something like:
if (accept(beginsym))
{
    do
    {
        statement();
    }
    while (accept(semicolon));
    expect(endsym);
}
This only accepts strings of the form:
"begin" statement { ";" statement } "end"
Or, am I missing something? This example code is as old as the hills so it seems unlikely that such a bug could've been around for so long, but I guess it's possible.
Update: The version of this example parser at the URL http://www.princeton.edu/~achaney/tmve/wiki100k/docs/Recursive_descent_parser.html has a modified version of the grammar to reflect this. I'll update the article when I get the chance.
Update: I updated the grammar. It now matches the grammar as specified on the PL/0 page (without the | "?" ident | "!" expression rule) and corresponds to the C implementation given.
--Richardcook (talk) 15:45, 18 July 2014 (UTC)
thread_title:  Another bug in example code 

message: Granted that this article doesn't have a history section at this point but this might be useful, from http://www.bayfronttechnologies.com/mc_tutorial.html
In 1990 when Donald Knuth was asked what helped to crystallize his thinking about attribute grammars he related the following [Knuth90].
    "Many details of those two days (February 4-5, 1967) still remain fresh in my mind. ... Peter [Wegner] asked me what I thought about formal semantics, and I said I liked Iron's idea of synthesizing an overall meaning from submeanings. I also said that I liked the way other people had combined Irons's approach with a top-down or "recursive-descent" parser; Irons had used a more complex parsing scheme. In particular, I was impressed by the metacompiler of Val Schorre [Schorre64] and by the more powerful (though less elegant) "transmogrifier" of Bob McClure [McClure65]."
[Knuth90]
D. E. Knuth, "The Genesis of Attribute Grammars," In Proceedings of the International Conference on Attribute Grammars and their Applications (Paris, France). P. Deransart and M. Jourdan, Eds. Springer-Verlag New York, New York, NY, 1-12. 1990.
The "other people" that he referred to were probably Waychoff et al. at Burroughs for whom he consulted, however they rarely published formally so he probably felt it inappropriate to name them. MarkMLl (talk) 11:56, 1 September 2017 (UTC)
thread_title:  Knuth on recursive descent