So, I just wanted to ask, is there somewhere a Lex-file
around which reads FORTRAN 77 (and/or Fortran 90)
around?
This would reduce my workload, I think...
(I don't think I can easily convert the existing
'C-accepting-lex-file', especially because of this
"blanks are not significant" / fixed source form in F77)
Thanx in advance,
Michael
--
Michael Schmitt /--------------------
Booth Research Center, UConn / kein Besandteil sein
(203)-486-1801 /----------------------
Lex is not adequate to do the job. You will need to write, or borrow,
a hand written lexer. However once lexed you can borrow, or write, a
YACC grammar for the rest of the task. Because YACC is a LALR(1)
parser, and the grammars in the standards are not LALR(1), you cannot
directly use that as a source. However, there are supposed to be
simple tricks to convert them into the proper form. Get the Dragon
Book as a guide to the conversion if necessary. Possible sources of
lexers and parsers include
1. F2C which has a parser, and I believe a YACC grammar. There may be
restrictions on their commerical use.
2. PCCTS, which is an LL(k) parser, i.e., not YACC compatible but does a
similar job, typically faster and easier to understand, has, I believe,
a Fortran grammar. If you are committed to YACC this may not be
acceptable. Check in the newsgroup comp.compilers.tools.pccts
3. Reasoning Systems, sells their REFINE Tools for this sort of
application, but again I don't think it is YACC compatible.
4. The moderator of comp.compilers in his FAQ mentions his F77
lexer/parser. Check in the newsgroup comp.compilers
5. Other compiler compilers have similar tools. Many of them are
listed in the comp.compilers FAQ. A posting in comp.compilers should
reveal many of them. Some of these tools are YACC compatible or easily
translated to YACC compatible form.
6. Some other Fortran analysis tools might provide lexers, e.g.,
Floppy, Flow, etc., see the Fortran FAQ.
YACC does not totally give up if the grammar is not LALR(1). The problems
of shift-reduce conflicts etc. (see Dragon Book, as WBC suggests) are
resolved by default, depending mainly on the ordering of the rules in
the input grammar. Not necessarily the resolution you would have
chosen. But YACC tells you where it found the conflicts and what it
did. Not easy to read if there are a lot of them.
As an example, YACC can produce a compiler for "dangling else" which
is well known to be ambiguous and not deterministically parsable. If
you write the grammar in a certain order, it will resolve the "else"
in the way most Algol/Pascal type compilers expect. [There is no
dangling else in Fortran because IF is terminated by END IF.]
--Loren Meissner
1. The CoSy Compilation System, used by ACE for their HPF compiler
not described in LL, LALR, or LR terms. Has an F90 parser
http://www.ace.nl/products/cosy.html
2. The Amsterdam Compiler Kit (ACK), an LL(1)? generator
http://www.cs.vu.nl/vakgroepen/cs/ack.html
3. Coco/R an LL(1) generator with C, Modula 2, and Oberon output
http://oberon.ssw.uni-linz.ac.at/projects.html
4. CENTAUR
not described in LL, LALR, or LR terms. Has an F90 parser
http://www.inria.fr/croap/centaur/centaur.html
5. PCCTS: an LL(n) system. The developer has done some work on an
F77 to F90 translator and should have most of an F77 parser and some
of an F90 parser
http://tempest.ecn.purdue.edu:8001/PCCTS/index.html
6. PRECC-X, mentioned above, another LL(n) system
http://www.comlab.ox.ac.uk/archive/redo/precc.html
7. Rie,
derived from bison so presumably LALR
ftp://ftp.is.titech.ac.jp/pub/Rie/
8. Mango, object oriented with Self language output
LALR or LR technology
http://self.smli.com/papers/mango.html
9. Flex
http://mehta.anu.edu.au:8080/flex/flex_toc.html
10. YOOCC and TROOPER, Eiffel based LL(1)
http://www.sd.monash.edu.au/~jona/
11. Parser in Python
http://csgrad.cs.vt.edu/~fdrake/Envision/Python/parser.html
As near as I can tell F90 grammars are available for
Cocktail, mentioned in a previous posting by Grosch
Cosy,
CENTAUR,
Lahey,
and perhaps PCCTS. Lahey, Cocktail and Cosy are commercial. Note
many F90 verndors offer to sell portions of their compiler technology,
it is not clear which of these would be useful to you.
WIlliam> As long as we're trying to be thorough, there is also
Gosh! Are all these relevant to lexing Fortran, though? For
instance, does flex overcome lex's problems in that regard?
Incidentally, does anyone know the reason for the traditional Fortran
syntax and the problems it causes not-so-modern generator systems,
presumably in terms of the original parsing techniques employed?