Re: flex + yacc problem: partial parsing.

Kaz Kylheku <kaz@kylheku.com>
Wed, 8 Jan 2014 03:18:39 +0000 (UTC)

          From comp.compilers

Related articles
flex + yacc problem: partial parsing. kaz@kylheku.com (Kaz Kylheku) (2013-12-17)
Re: flex + yacc problem: partial parsing. kaz@kylheku.com (Kaz Kylheku) (2014-01-07)
Re: flex + yacc problem: partial parsing. kaz@kylheku.com (Kaz Kylheku) (2014-01-08)
Re: flex + yacc problem: partial parsing. kaz@kylheku.com (Kaz Kylheku) (2014-01-08)
| List of all articles for this month |
From: Kaz Kylheku <kaz@kylheku.com>
Newsgroups: comp.compilers
Date: Wed, 8 Jan 2014 03:18:39 +0000 (UTC)
Organization: Aioe.org NNTP Server
References: 13-12-008
Keywords: yacc, lex
Posted-Date: 08 Jan 2014 00:58:37 EST

On 2013-12-17, Kaz Kylheku <kaz@kylheku.com> 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:


http://www.kylheku.com/cgit/txr/commit/?id=c5accb635a0892c685947aa0bb45193f4cd5cb38


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
    job.


----


* 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: http://www.kylheku.com/diy
ADA MP-1 Mailing List: http://www.kylheku.com/mp1


Post a followup to this message

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