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


Groups > comp.compilers > #1072

Re: flex + yacc problem: partial parsing.

Path csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!us.feeder.erje.net!news.linkpendium.com!news.linkpendium.com!news.iecc.com!.POSTED!nerds-end
From Kaz Kylheku <kaz@kylheku.com>
Newsgroups comp.compilers
Subject Re: flex + yacc problem: partial parsing.
Date Tue, 7 Jan 2014 23:56:02 +0000 (UTC)
Organization Aioe.org NNTP Server
Lines 68
Sender johnl@iecc.com
Approved comp.compilers@iecc.com
Message-ID <14-01-005@comp.compilers> (permalink)
References <13-12-008@comp.compilers>
NNTP-Posting-Host news.iecc.com
X-Trace leila.iecc.com 1389160610 10249 64.57.183.58 (8 Jan 2014 05:56:50 GMT)
X-Complaints-To abuse@iecc.com
NNTP-Posting-Date Wed, 8 Jan 2014 05:56:50 +0000 (UTC)
Keywords lex, yacc
Posted-Date 08 Jan 2014 00:56:50 EST
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:1072

Show key headers only | View raw


On 2013-12-17, John added:
> [You can use YYACCEPT to tell yacc or bison that you're done parsing,
> but I'm not sure about the readahead. -John]

Thanks a lot for that heads up.

I have done an experiment which shows that the readahead will in fact be
suppressed.

However, it requires cooperation from the grammar, so a trivial sprinkling of
YYACCEPT in my actual grammar doesn't do the trick. I already know quite
exactly what the reason is: in my grammar, an expr (that I'm trying to
extract) can be "expr DOTDOT expr" where DOTDOT is a .. operator.
For this reason, we cannot reduce expr to the start symbol without looking
ahead to see whether there is a DOTDOT token, and so by the time we get
to the rule associated with that reduction, the lookahead has taken place.

However, the following test program shows that lookadhead is not performed
unnecessarily to do a reduction which doesn't require it.

If we leave YYACCEPT commented out, then the message "token!" is printed
twice (showing that yylex is called twice) and there is a syntax error.
This is most likely because the parser is processing the embedded rule:

    0 $accept: S . $end

and the scanner has returned another FOO.

If we uncomment YYACCEPT, then yylex is called only once, and the parse
succeeds, showing that no lookahead was performed to achieve the reduction
of S <- FOO, and the $accept <- FOO $end reduction is nicely skipped.

I think I have enough info to make progress on this. Thanks again.

%{
#include "y.tab.h"
void yyerror(const char *str);
%}

%token FOO
%type<str> S

%%

S : FOO { /* YYACCEPT; */ };

%%

int yylex(void)
{
  puts("token!");
  return FOO;
}

void yyerror(const char *str)
{
  puts(str);
}

int main(void)
{
  yyparse();
}


--
Music DIY Mailing List: http://www.kylheku.com/diy
ADA MP-1 Mailing List:  http://www.kylheku.com/mp1

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

flex + yacc problem: partial parsing. Kaz Kylheku <kaz@kylheku.com> - 2013-12-17 22:52 +0000
  Re: flex + yacc problem: partial parsing. Kaz Kylheku <kaz@kylheku.com> - 2014-01-07 23:56 +0000
  Re: flex + yacc problem: partial parsing. Kaz Kylheku <kaz@kylheku.com> - 2014-01-08 03:18 +0000
    Re: flex + yacc problem: partial parsing. Kaz Kylheku <kaz@kylheku.com> - 2014-01-08 18:29 +0000

csiph-web