Re: Anything better than lex & yacc? Everyone still using those?

feriozi@my-deja.com
30 Jun 2000 10:17:25 -0400

          From comp.compilers

Related articles
Anything better than lex & yacc? Everyone still using those? spamtrap@tic0.net (Tuukka Tikkanen) (2000-06-30)
Re: Anything better than lex & yacc? Everyone still using those? feriozi@my-deja.com (2000-06-30)
Re: Anything better than lex & yacc? Everyone still using those? idbaxter@semdesigns.com (Ira D. Baxter) (2000-06-30)
Re: Anything better than lex & yacc? Everyone still using those? mihai@cs.wisc.edu (Mihai Christodorescu) (2000-06-30)
Re: Anything better than lex & yacc? Everyone still using those? iank@idiom.com (2000-07-01)
Re: Anything better than lex & yacc? Everyone still using those? pedwards@dmapub.dma.org (2000-07-01)
Re: Anything better than lex & yacc? Everyone still using those? isaac@latveria.castledoom.org (2000-07-04)
Re: Anything better than lex & yacc? Everyone still using those? jerry@swsl.co.uk (2000-07-04)
[3 later articles]
| List of all articles for this month |
From: feriozi@my-deja.com
Newsgroups: comp.compilers
Date: 30 Jun 2000 10:17:25 -0400
Organization: Deja.com - Before you buy.
References: 00-06-112
Keywords: parse, tools

    "Tuukka Tikkanen" <spamtrap@tic0.net> wrote:


> C++ support should include
> encapsulation of lexer and parser in classes to avoid cluttering of
> global namespace, to achieve re-entrancy and to support easy use of
> multiple parsers within same program, possibly within same input
> stream.


Having lexer/parser classes causes the "white box" problem. At the
very least, the parser needs to know about the lexer in order to
invoke it. I prefer the black box approach of traditional C, where the
module interface is simpler. My parser-generator creates a file-level
C "class" as a parser. The only public is the name of the parsing
function. The arguments to the parser include pointers to a scanner,
an error routine, and an action call table. This method of separation
results in very strong modularity.


Re-entrancy just means that there is no global data. C++ is not needed
for this.


Multiple parsers are supported by allowing the name of the parsing
routine to be specified at creation time.


Obviously, multiple scanners could be used on different inputs. It is
hard for me to envision a case where multiple parses of the same stream
would occur at the same time, or even in succession. The problem would
be specifying the end marker, which must be a token outside of the
grammar.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.