Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.compilers > #941

yacc expectations of yylex()

Path csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!news-out.readnews.com!news-xxxfer.readnews.com!news.misty.com!news.iecc.com!.POSTED!nerds-end
From Andrew Smallshaw <andrews@sdf.lonestar.org>
Newsgroups comp.compilers
Subject yacc expectations of yylex()
Date Mon, 15 Jul 2013 20:58:11 +0000 (UTC)
Organization A noiseless patient Spider
Lines 29
Sender johnl@iecc.com
Approved comp.compilers@iecc.com
Message-ID <13-07-010@comp.compilers> (permalink)
NNTP-Posting-Host news.iecc.com
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
X-Trace leila.iecc.com 1373943114 23460 64.57.183.58 (16 Jul 2013 02:51:54 GMT)
X-Complaints-To abuse@iecc.com
NNTP-Posting-Date Tue, 16 Jul 2013 02:51:54 +0000 (UTC)
Keywords lex, question
Posted-Date 15 Jul 2013 22:51:54 EDT
X-submission-address compilers@iecc.com
X-moderator-address compilers-request@iecc.com
X-FAQ-and-archives http://compilers.iecc.com
Xref csiph.com comp.compilers:941

Show key headers only | View raw


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


Thread

yacc expectations of yylex() Andrew Smallshaw <andrews@sdf.lonestar.org> - 2013-07-15 20:58 +0000

csiph-web