|Hand written or tool generated lexical analyzers for FORTRAN email@example.com (Pankaj) (2005-09-14)|
|Re: Hand written or tool generated lexical analyzers for FORTRAN firstname.lastname@example.org (glen herrmannsfeldt) (2005-09-15)|
|Re: Hand written or tool generated lexical analyzers for FORTRAN email@example.com (Fred J. Scipione) (2005-09-17)|
|Re: Hand written or tool generated lexical analyzers for FORTRAN firstname.lastname@example.org (glen herrmannsfeldt) (2005-09-18)|
|Re: Hand written or tool generated lexical analyzers for FORTRAN email@example.com (Pankaj) (2005-09-27)|
|Re: C scanners, was Hand written or tool generated lexical analyzers f firstname.lastname@example.org (Russ Cox) (2005-09-30)|
|Re: C scanners, was Hand written or tool generated lexical analyzers f email@example.com (2005-10-02)|
|Re: C scanners, was Hand written or tool generated lexical analyzers f firstname.lastname@example.org (Vesa Karvonen) (2005-10-13)|
|From:||"Fred J. Scipione" <email@example.com>|
|Date:||17 Sep 2005 13:53:14 -0400|
"glen herrmannsfeldt" <firstname.lastname@example.org> 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.
>> [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
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
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
Return to the
Search the comp.compilers archives again.