Include files and yacc grammars

smk@dcs.edinburgh.ac.uk
Thu, 16 Apr 1992 14:18:25 GMT

          From comp.compilers

Related articles
Include files and yacc grammars jao@red6.acpub.duke.edu (1992-04-15)
Include files and yacc grammars smk@dcs.edinburgh.ac.uk (1992-04-16)
| List of all articles for this month |

Newsgroups: comp.compilers
From: smk@dcs.edinburgh.ac.uk
Keywords: design
Organization: Compilers Central
References: 92-04-061
Date: Thu, 16 Apr 1992 14:18:25 GMT

JOSEPH OSWALD writes:
[how to do include files in yacc given the possible one-token lookahead]
I had once a similar problem and solved it as follows:


The includes were done by the lexer itself, but with some support by the
parser. The idea is that you use lexer's states.


    statement : ... /* usual stuff */
                        | INCLUDE '(' statement ')' ';'
                        | ...


This doesn't mean that there is a statement in the parentheses,
it is just the expanded file.


The lexer changes its state, so you have something like:


<INITIAL>"include" { BEGIN EXPECTPAR; return INCLUDE;}
<EXPECTPAR>"(" { BEGIN INCLFILE; return '('; }
<INCLFILE>{string} { BEGIN INITIAL; files++; yyin=fopen(yytext,"r"); }


Notice that the <INCLFILE> line has no return-statement, i.e. lexer and
parser go on as if nothing has happened, except that the input now comes
from the include file -- its content is parsed by the parser as usual; if
EOF is reached, yywrap is called and here you can check the variable
`files' to distinguish between EOF of stdin and EOF of an include-file.


You might have some more sophisticated actions, e.g. to apply some
function to yytext to get its meaning, to support error messages talking
about the file they occur, to allow includes in includes, etc. You also
might want a special state rather than INITIAL to scan an include file,...


One disadvantage of treating INCLUDE in the lexer is that you cannot
(easily) write


include(f(x));


where f is a function that has to compute the filename yet. This does not
make much sense in compilers (languages that are supposed to be compiled),
but in interpreters there is no principle problem with it. The most
logical way to treat it seems to be a separate parser to parse the
argument of include (and to evaluate it wrt. the actual symbol table), at
least this sledgehammer method solves any lookahead problems.
--
Stefan M. Kahrs JANET: smk@uk.ac.ed.dcs
LFCS, Dept. of Computer Science Internet: smk@dcs.ed.ac.uk
University of Edinburgh UUCP: ..!mcvax!ukc!lfcs!smk
Edinburgh EH9 3JZ ARPA: smk%dcs.ed.ac.uk@nsfnet-relay.ac.uk
SCOTLAND Tel: 044-31-650-5139
--


Post a followup to this message

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