Related articles |
---|
yacc expectations of yylex() andrews@sdf.lonestar.org (Andrew Smallshaw) (2013-07-15) |
From: | Andrew Smallshaw <andrews@sdf.lonestar.org> |
Newsgroups: | comp.compilers |
Date: | Mon, 15 Jul 2013 20:58:11 +0000 (UTC) |
Organization: | A noiseless patient Spider |
Keywords: | lex, question |
Posted-Date: | 15 Jul 2013 22:51:54 EDT |
The brief background to this it that I have an interactive command
interpreter currently written in flex and yacc as a quick testbed
pending to get things working pending doing the job "properly". I was
never entirely happy using flex long-term because a) I depend on
actions that are flex specific in an app that is supposed to be pure
POSIX and b) converting between the app's internal data format and
character arrays is a slightly costly and conceptually messy process.
Using a hand-written lexer with the existing yacc parser would seem to
avoid these issues and since my requirements are fairly simple it
amounts to a couple of hundred lines of code.
However, I am currently clarifying the precise nature of the glue
between yacc and the lexer. It appears to me that essentially this
consists of the returned value of yylex() itself, YYSTYPE and yylval.
Any other variables, in particular yyleng and yytext, are not needed
by the parser itself and are there for the convenience of lex actions.
If my hand-written parser never needs that data or can get it from
somewhere else I don't actually need to implement them.
Is this right or have I overlooked something?
--
Andrew Smallshaw
andrews@sdf.lonestar.org
[That's right. The parser calls yylex() and looks at
the return value for the token and yylval for the associated
token value. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.