Related articles |
---|
Backtracking yacc jarmo@ksvltd.FI (Jarmo Raiha) (1992-09-10) |
Parsers are easy to write (was: Re: Backtracking yacc) markh@csd4.csd.uwm.edu (1992-09-25) |
Quantum Parsing (was: Re: Parsers are easy to write) markh@csd4.csd.uwm.edu (1992-09-28) |
Re: Quantum Parsing (was: Re: Parsers are easy to write) dak@kaa.informatik.rwth-aachen.de (1992-09-30) |
Re: Quantum Parsing (was: Re: Parsers are easy to write) markh@csd4.csd.uwm.edu (1992-10-03) |
Newsgroups: | comp.compilers,comp.theory |
From: | dak@kaa.informatik.rwth-aachen.de (David Kastrup) |
Organization: | Rechnerbetrieb Informatik / RWTH Aachen |
Date: | Wed, 30 Sep 1992 08:52:05 GMT |
References: | 92-09-059 92-09-185 92-09-194 |
Keywords: | parse, LL(1), yacc, comment |
Ever written a parser for @#%$#@ Fortran? Remember, spaces are ignored,
and there are no reserved words. So strictly speaking you can write
12 FORMAT(I) = 7
which means something abysmally different from
12 FORMAT(I)
Note that practically all existing fortran compilers complain at some
-well- perfectly legal code. Another example:
DO 10 I=1
is an assignment of variable DO10I
DO 10 I=1,10
is a loop.
Write a parser for that, if you like. And building a recursive thing
with backtracking and certain state values produces essentially nothing
that a parser generator could not produce. Only that you may be less
efficient. Only pretty simple grammars can be substantially faster
parsed by a handwritten parser.
[I wrote a yacc parser for Fortran, using a prepass over each statement to
decide whether it's an assignment or not. It wasn't that hard to do. It's
in the compilers archives for anyone who cares. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.