# Re: predictive parsing and non-recursive predictive parsing

## Max Hailperin <max@gustavus.edu>

Tue, 24 Jun 2008 07:40:13 -0500

*From comp.compilers*

| List of all articles for this month |

**From: ** | Max Hailperin <max@gustavus.edu> |

**Newsgroups: ** | comp.compilers |

**Date: ** | Tue, 24 Jun 2008 07:40:13 -0500 |

**Organization: ** | Compilers Central |

**References: ** | 08-06-053 |

**Keywords: ** | parse, LL(1) |

**Posted-Date: ** | 24 Jun 2008 21:26:11 EDT |

unix.sh@gmail.com writes:

*> I have one question regarding the difference between those two:*

*>*

*> I can use recursive predictive parsing, which is very straightforward.*

*> So what's the advantage of non-recursive predictive parsing. To*

*> perform non-recursive parsing, I need to construct FIRST, FOLLOW sets*

*> and use explicit stack. On the other hand, recursive predictive*

*> parsing is very easy to understand. I understand non-recursive calls*

*> have a better performance than recursive one. Is this the only reason?*

The only reasons that I can think of to distinguish between

recursive-descent predictive parsers and explicit-stack predictive

parsers are esthetics and efficiency. Efficiency includes efficiency

of parser construction, whether manual or using a parser generator, as

well as of parsing.

Your comments about FIRST and FOLLOW sets are misleading. You need to

find the FIRST sets in order to make either kind of predictive parser,

even recursive descent. And you don't absolutely need to find the

FOLLOW sets to make either kind of predictive parser, even the

explicit-stack kind. However, if you don't know the FOLLOW sets, you

won't be able to check at parser construction time that your grammar

is really ammenable to predictive parsing, and you won't be able to

produce as high quality of syntax error messages at parse time. Those

motivations for finding the FOLLOW sets apply equally well to both

kinds of predictive parsers.

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.