yacc expectations of yylex()

Andrew Smallshaw <andrews@sdf.lonestar.org>
Mon, 15 Jul 2013 20:58:11 +0000 (UTC)

          From comp.compilers

Related articles
yacc expectations of yylex() andrews@sdf.lonestar.org (Andrew Smallshaw) (2013-07-15)
| List of all articles for this month |
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]



Post a followup to this message

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