I have not heard anything on this since Michel Olagnon's response to David B.
Serafini's proposal.
> Date: Wed, 12 Nov 1997 10:47:36 -0600 (CST)
> From: "David B. Serafini" <[log in to unmask]>
> <snip>
> In the spirit of the GNU and Linux efforts, I think we, the F90 community,
> should join together to produce a portable, free F90 code parser written
>in F90
> and use it to build tools such as this one. Once the parser is in
>place, most
> of the tools (a pretty printer that produced TeX output, for example, or a
> "lint" type of program checker, etc). If we all worked together on
>this, I bet
> we could do it in short order. I think most of the work has already
>been done
> in various places, it's just a matter of packaging it all together in a
> consistent form, developing and documenting an API, and distributing it.
> <snip>
As I have an interest in parsing Fortran 90 I thought I should comment. I
have a strong suspicion that while much of the work has been done separately
the lack of coordination has resulted in code which will take almost as much
effort to integrate as it would take to develope it from scratch. Further, I
have a strong suspicion that much of the code has been written in C and is
not highly portable.
I would still encourage the pursuit of this project. I would suggest that we
accept code in other languages where ever necessary, but require Fortran
compatible file formats (perhaps using f2c for file I/O), relatively simple
API's for such codes (so that Fortran bindings are not onerous), and think
about creating true F90 replacements in the long term.
As I view this, this project is about creating tools usefull for Fortran
programmers, with an emphasis on F90/95 programmers, and an emphasis on tools
related to parsing Fortran. Such parsing related tools might include a
regular expression package, a parser generator, a parser, a Fortran source to
source translator, a Fortran source code checker (lint), a g77 like compiler,
a better C2F translator, etc, It is possible that such a project might
eventually include non-parser related codes. Of the projects that I identify
above:
1. Regular expression package: One of the most common parsing tasks involves
the parsing of regular expressions. There does not appear to be a well
establishe Fortran based package for this task. There was an article in a
recent ACM journal, I believe Transactions on Programming Languages, that
discussed in detail the characteristics of the ideal regular expression
package. It appears that most (all?) widely available such packages are not
as robust or flexible as the ideal. I believe that this article could serve
as the basis of the developement of a strong Fortran 90 based regular
expression package.
2. Parser generator: One of the reasons for the lack of Fortran parsers is
the lack of tools that facilitate the construction of such parsers. It should
be possible to create such a tool based on pre-existing C/C++/Java code. Such
tools (I cite only freely available tools) include
A. Lex/YACC: perhaps the best known such tool with numerous variants,
FLEX, YACC++, etc. These are based on LALR(1) parsing technology. The LALR
implies bottom up parsing, which can be difficult to understand, the (1)
implies that it can easilly handle only lookaheads of one token which means
it is not well suited for complex grammars.
B. PCCTS/ANTLR: The Purdue compiler construction tool set was originally
created to facilitate the parsing of Fortran for an Army funded project. It
was originally written in C, but the main tool, ANTLR, has been rewritten in
Java and now incorporates most of the functionality of the rest of the
toolset. It uses LL(k) parsing technology. The LL implies top down parsing,
which is typically easier to understand than LALR parsing but can typically
handle a smaller set of grammars at a given amount of lookahead. The (k)
implies that it can in principle handle lookaheads of arbitrary numbers of
tokens (it uses a special algorith to simplify processing for such cases).
The higher lookahead makes it more suitable for complex grammars. It has its
own newsgroup, comp.compilers.tools.pccts.
C. PRECCX: The Prettier Compiler constructor extended. I know little
about this but I believe it is written in C and accepts LL(k) grammars and
generates output for processing by YACC. It is supported by a group based in
the UK.
D. ELI: A compiler generator written in C. I believe it accepts LL(k)
grammars. It is supported primarilly by a group based at the University of
Colorado, under William Waite, in cooperation with Australian and German
academics. It relies on a large number of other C based tools for
intermediate processing, e.g., Funnelweb, Tcl/Tk, (YACC?), etc., and appears
to be strongly tied to Unix.
E. Cocktail: Only partly in the public domain. I believe current
non-public domain versions accept LALR(k) grammars, and generate either C++,
Modula 2, or Oberon code.
Of the above compilers I suspect that YACC or ANTLR most likely have the
appropriate combination of simplicity and flexibility to serve as a basis for
a Fortran compiler generator.
3. Parser: I know of only one apparently freely available parser for Fortran
90, William Waite's parser for Eli. Because of Eli's strong reliance on other
tools and lack of portability outside the Unix world, I would be reluctant to
recommend the direct use of this parser. However, Waite's paper describing
the parser should serve as a guide to the creation of a parser, either
handwritten or using a tool such as PCCTS.
4. The utilization of a parser for a source to source translator or a general
purpose compiler requires the definition of an AST (abstract syntax tree). It
would be best to define a common form for such transformations, which
suggests that we whould be aware of the forms used by some potential
backends. As perhaps the most widely used backend is that of gcc we should
have someone investigate its requirements.
5. We will also need specification of the parser's equivalent of a .mod file
for the compiler, lint, etc.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
