LR Parser and Lexer Generators: Fortran Files

I haven't polished the "make" files.

To compile lr, copy one of the .configure* files and change it according
to your taste. All the make files "include" .configure.  The PLAT
variable is the name of a subdirectory in the "lib", "lex", and "lr"
directories, usually the name of a compiler, but you can choose anything.
Create those subdirectories, e.g.

  setenv PLAT my_plat # or export PLAT=my_plat if you use bash
  mkdir lib/${PLAT} lex/${PLAT} lr/${PLAT}

I have provided .configure.nagfor, .configure.ifort, and
.configure.gfortran. I make a soft link from one of them to .configure.

Compile the MakeDep.f90 program and put it somewhere in your path.

then

  cd lib/${PLAT}
  make depends liblr.a
  cd ../../lr/${PLAT}
  make depends lr

There are some other make files that don't work.

If you devise a smoother system, please share it with me.

The syntax for grammars is described in comments in the grammar for
grammars in the file lr/lr.grm.

There is an infrastructure in lib and some procedures in lr that will be
useful to use the parser in your projects.

The symbol_types.f9h file is generated automatically by the GenSym program
from the symbol_types_lr.in file. Comments in that input file explain how
to use GenSym.

The string_table module is where characters are read, and accumulated
into strings. Each string gets a string index. Strings are not duplicated.

There is a simple symbol_table module. Entries in the symbol table are
indexed by the string index. Their values are indices in the declaration
table. Each element of the declaration table has a "prior" index, for
another declaration of the same symbol. Within LR, this is used to make
sure that a symbol is not used as both a terminal symbol and a nonterminal
symbol, that a string to provide the name of a tree vertex (for debugging
purposes) is declared, and that a mapping from a pseudo-terminal symbol to
the tree node to be created for it is in fact a mapping for a terminal
symbol. Pseudo-terminal symbols are those that have an internal lexical
structure, and for which there might be several instances, such as
identifiers, strings, and numbers.

The tree that the parser generates is stored in "CDR code," which
apparently first appeared in McCarthy's LISP compiler: Each vertex has its
identity, its number of sons, and the index in the tree of its first sons
(if it's not a leaf). Sons are stored in consecutive positions. The type
definition, and a lot of procedures useful for working with the tree, are
in the tree module. In a leaf, instead of the index of the first son
there's a "sub rosa" index -- a string table index -- to provide the
string for pseudo-terminals such as identifiers, numbers, strings, ....

The Flatten_m module in LR is a simple example of how to use the tree.

I have an older example in Ada -- a very simple compiler that I gave to
students as the starting point for lab exercises. It uses essentially the
same infrastructure, but an obsolete representation for the LR output. Ask
me for it if you want it.

I used LR as the parser for a "little language" used to drive a very
large program, but I don't know whether I'm allowed to give that away
without you first getting a license from Caltech.

Feel free to ask questions.

Van Snyder
van.snyder@sbcglobal.net