|Is Fortran90 LL(1)? firstname.lastname@example.org (Christian Rutzinger) (1996-04-04)|
|Re: Is Fortran90 LL(1)? email@example.com (1996-04-08)|
|Is Fortran90 LL(1)? firstname.lastname@example.org (Dave Lloyd) (1996-04-08)|
|Re: Is Fortran90 LL(1)? email@example.com (1996-04-16)|
|Re: Is Fortran90 LL(1)? Robert.Corbett@Eng.Sun.COM (1996-04-18)|
|From:||firstname.lastname@example.org (Mark Johnson)|
|Date:||8 Apr 1996 15:49:50 -0400|
|Organization:||Hughes Training, Inc.|
Christian Rutzinger <email@example.com> wrote:
>I want to write a Recursive Descent Parser for Fortran90. ,,,
>Am I wrong, or is (Standard) Fortran90 really a not LL(1) language?
FORTRAN is definitely not LL(1). A good example is the difference
between the following two statements
DO 10 I=1,10
DO 10 I=1.10
[the real difference is the comma in the first one & the period in
the second example]
The first starts a DO loop, using [implicitly integer] I as an index,
counting from 1 to 10. [7 tokens - DO, 10, I, =, 1, ",", and 10]
The second assigns the value 1.1 to the [implicitly real] variable DO10I.
[only 3 tokens - DO10I, =, 1.10]
Needless to say, you sometimes have to examine the entire statement
before you know what kind it is & generate tokens. One approach to handle
this is to do something like...
call statement_type(current_state, new_state, s_type, line)
<computed goto based on s_type, etc.>...
where the statement_type procedure uses the "current state" and the input
line(s) to determine the statement type "s type" and "new state". The
"current state" and "next state" represent the language rules relating to
the order of statements. This solution isn't very efficient, and dumps a lot
of functionality into the statement_type procedure. But it is a robust
and somewhat easy to describe solution. There are undoubtedly others who
could supply more optimal solutions.
Good luck on your work.
-- Mark Johnson <firstname.lastname@example.org>
[I put a little Fortran subset parser in the comp.compilers archives several
years ago. It uses a yacc parser and a lot of lexical feedback. It's not
complete, but the structure is adequate to parse all of Fortran. -John]
Return to the
Search the comp.compilers archives again.