gnupic: Re: special numbers
Subject:
Re: special numbers
From:
Scott Dattalo ####@####.####
Date:
10 Sep 2004 17:27:28 +0100
Message-Id: <Pine.LNX.4.60.0409100906050.22734@ruckus.brouhaha.com>
On Fri, 10 Sep 2004, pico wrote:
> I don't like Scott's suggestion because i don't see the proposed solution.
> Craig, please correct my, if i wrong.
In general, you want to perform lexical analysis in the lexer and parsing
in the parser. Anytime you lex in the parser or parse in the lexer then
this means either the grammer is ambiguous in some way (and consequently
difficult for an LALR parser) or the application programmer is having
trouble disambiguating the grammer. I'm by no means an expert in bison and
flex, but I've struggled with it enough to know that when I try to parse
in the lexer that it's a good hint that I'm probably doing something
wrong! (Lexing in the parser is a little more forgiving...)
The suggestion I made to Craig is that the lexer only needs to convert the
input character stream into a token stream. Depending on the token stream,
the parser may decide to tell the lexer to switch the way tokens are
converted. To the case in point, if the parser knows that a processor
identifer is to be expected next, it will then instruct the lexer to look
for a processor identifier. In your particular example, the 'set'
directive expansion will be ignored while the lexer is in the 'processor
identifier' mode. Now, there are only two instances where processor
identifiers are expected. One is with the PROCESSOR directive and the
other is with the list directive. Each of these should have a uniquely
distinguishable parser rule that recognizes when the situation is about to
happen. When the rule triggers, the parser can tell the lexer to switch
states. When the processor identifier has been fully identified then
either the lexer or parser can switch back to the previous state.
Is that explaination a little more clear?
Scott
