Re: flex + yacc problem: partial parsing.

Kaz Kylheku <>
Wed, 8 Jan 2014 03:18:39 +0000 (UTC)

          From comp.compilers

Related articles
flex + yacc problem: partial parsing. (Kaz Kylheku) (2013-12-17)
Re: flex + yacc problem: partial parsing. (Kaz Kylheku) (2014-01-07)
Re: flex + yacc problem: partial parsing. (Kaz Kylheku) (2014-01-08)
Re: flex + yacc problem: partial parsing. (Kaz Kylheku) (2014-01-08)
| List of all articles for this month |

From: Kaz Kylheku <>
Newsgroups: comp.compilers
Date: Wed, 8 Jan 2014 03:18:39 +0000 (UTC)
Organization: NNTP Server
References: 13-12-008
Keywords: yacc, lex
Posted-Date: 08 Jan 2014 00:58:37 EST

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

Okay, I got it all working:

In a nutshell:

- had to refactor the grammar so that that an expr can be reduced to the
    start symbol without any lookahead token, as a $default reduction:
    all entries in the parsing table say "reduce", regardless of
    the lookahead token. *-note

- had to add the YYACCEPT; trick to the top reduction.

- to completely solve the lookahead problem down to the lexical level
    (so after extracting an expr, the stream is left in the proper state so that
    another expr can be extracted), I had to change the YYINPUT macro
    to only return one byte at a time. If YYINPUT reads more than one
    byte from the stream, then these accumulated bytes will be thrown
    away when the lexical machine is reinitialized for another yyparse


* This is usually trivial in Lisp grammars, except that I support an
    a .. b operator which is a syntactic sugar for (cons a b), which means
    that if we parse the "a", we need lookahead to determine whether the
    next thing is "..", or EOF. I refactored it by making the .. operator
    part of the syntax of a compound list expression; it cannot occur
    by itself any more, which is perfectly acceptable. In other words,
    a .. b is now just syntax, on par with something like the consing
    dot notation, and not an independent expression. You'd never want
    a top-level expression that is just the equivalent of (cons a b).

Music DIY Mailing List:
ADA MP-1 Mailing List:

Post a followup to this message

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