Re: Hand written or tool generated lexical analyzers for FORTRAN

"Fred J. Scipione" <fjscipio@rochester.rr.com>
17 Sep 2005 13:53:14 -0400

          From comp.compilers

Related articles
Hand written or tool generated lexical analyzers for FORTRAN pankaj.jangid@gmail.com (Pankaj) (2005-09-14)
Re: Hand written or tool generated lexical analyzers for FORTRAN gah@ugcs.caltech.edu (glen herrmannsfeldt) (2005-09-15)
Re: Hand written or tool generated lexical analyzers for FORTRAN fjscipio@rochester.rr.com (Fred J. Scipione) (2005-09-17)
Re: Hand written or tool generated lexical analyzers for FORTRAN gah@ugcs.caltech.edu (glen herrmannsfeldt) (2005-09-18)
Re: Hand written or tool generated lexical analyzers for FORTRAN pankaj.jangid@gmail.com (Pankaj) (2005-09-27)
Re: C scanners, was Hand written or tool generated lexical analyzers f rsc@swtch.com (Russ Cox) (2005-09-30)
Re: C scanners, was Hand written or tool generated lexical analyzers f nmm1@cus.cam.ac.uk (2005-10-02)
Re: C scanners, was Hand written or tool generated lexical analyzers f vesa.karvonen@cs.helsinki.fi (Vesa Karvonen) (2005-10-13)
| List of all articles for this month |

From: "Fred J. Scipione" <fjscipio@rochester.rr.com>
Newsgroups: comp.compilers
Date: 17 Sep 2005 13:53:14 -0400
Organization: Road Runner
References: 05-09-054 05-09-061
Keywords: Fortran, parse
Posted-Date: 17 Sep 2005 13:53:14 EDT

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote
> Pankaj wrote:


>> But I still feel that a tool to generate a lexical analyzer for
>> FORTRAN would be a good idea. It will enable us to maintain the code
>> in the long run.
>
> (snip)
>
>> [I don't see the point. The only language with a lexical structure
>> like Fortran is Fortran, so once you have a Fortran lexer, you're
>> done. Having written a Fortran lexer, I can report that it's not
>> particularly hard, but it's quite context sensitive, particularly
>> if you want to handle old programs where blanks don't matter, so
>> you need some way to feed back info from the parser. -John] ...


> As long as fixed form is allowed one will still have to write
> lexers for newer versions of Fortran as they appear. In free format
> blanks are significant, so more usual lexers might work fine.


This discussion has reminded me of a thought I had following the
expositions in this news group on Quantum Parsers and Quantum
Grammars. You may recall (or look-up :-)) that the threads included
demonstrations of the idea that there is an algebra for parser
descriptions that allows both the language terms and action items
(code segments) to be manipulated without changing their semantics (or
at least that is my poor paraphrasing of one of the demonstrated
ideas).


It seemed to me that by characterizing certain actions as having the
effect of sending (or receiving) a message, it might be possible to
use the algebra to make a model of cooperation between several
processes. In particular, to model the synchronization between a
lexer, a parser, and a symbol table manager. Such a model might be
useful to illustrate some structure in, and demonstrate the
correctness of, what is now regarded as ad-hoc code in Lex and Yacc
grammars.


The Quantum Grammar concept was used to demonstrate how a pair of
stacks can be simplified to an attached precedence attribute for
certain stack entries. It may be similarly possible to demonstrate
that certain 'ad-hoc' action are the simplified residue of more
comprehensive features associated with (conceptual) FIFO and LIFO ques
(or perhaps state changes) within the three processes.


The original poster might be satisfied with a demonstration (in Lex
and Yacc 'grammars') of a proven correct cooperation scheme for
parsing Fortran, rather than requiring a new tool. Such a proof and
demonstration might be useful for C and other languages as well. It
might even lead to the addition of features in Lex and Yacc to
formally and correctly support such cooperation.


Maybe such a proof would even elicit a quantum grammar for full
C (not just a sub-set) or Yacc specification that included the
symbol table manipulations, etc. to handle labels and typedefs :-).
While the development of such a model exceeds my puny grasp, there
are certainly others in this group that have demonstrated much
greater abilities!



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.