Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #941
| From | Andrew Smallshaw <andrews@sdf.lonestar.org> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | yacc expectations of yylex() |
| Date | 2013-07-15 20:58 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <13-07-010@comp.compilers> (permalink) |
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]
Back to comp.compilers | Previous | Next | Find similar | Unroll thread
yacc expectations of yylex() Andrew Smallshaw <andrews@sdf.lonestar.org> - 2013-07-15 20:58 +0000
csiph-web