Related articles |
---|
Basic Yacc Question mbbad@s-crim1.daresbury.ac.uk (1995-04-05) |
Re: Basic Yacc Question salomon@silver.cs.umanitoba.ca (1995-04-14) |
Re: Basic Yacc Question ct7@datatel.com (1995-04-20) |
Newsgroups: | comp.compilers |
From: | mbbad@s-crim1.daresbury.ac.uk (I. Badcoe) |
Keywords: | yacc, design, question, comment |
Organization: | SERC Daresbury Lab, Warrington, U.K. |
Date: | Wed, 5 Apr 1995 10:10:06 GMT |
Hi,
I hope this is remotely the right place but there doesn't seem to be
a *.yacc.* hierarchy.
Basically I picked up the Gnu-Bison documentation and started to read
through it with a view to creating a pre-processor. Everything is (nearly)
clear to be *except* if (as in this case) you're writting an interpretter
instead of a compiler, how do you implement a definite-loop ? Several
ways occured to me but none of them seem particularly 'clean':
(i) Hack the lexer so that the parser can send it "Repeat this block N times"
This is unclean since it requires the lexer to do some parsing (to
handle nested loops).
(ii) Hack the lexer so that it can be told "Mark this point" and "Return to
this point". This is the cleanest of these 3 ? It's a bit
inefficient as it requires the multiple lexing/parsing of part of
the file, however.
(iii) Make a rule that it outputs the token values of some (bracketed) part of
the file into a buffer. Imply this rule for the bodies of loops and
then repeatedly pass the buffer to the lexer as the (pre-lexed) tokens
to be used next. I'm not sure that an "output token values of" rule
could be implemented, however.
Perhaps I'm completely misunderstanding the parse-process ? It's always the
case that you can only really understand documentation *after* you've
understood it :).
Badders
[I'd parse the entire program and turn it into RPN or trees, then run my
interpreter on that. Interpreting on the fly is a losing battle for any but
the most simple languages. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.