Re: Is Fortran90 LL(1)?

mjohnson@samson.tx.hac.com (Mark Johnson)
8 Apr 1996 15:49:50 -0400

          From comp.compilers

Related articles
Is Fortran90 LL(1)? rutzinger@takefive.co.at (Christian Rutzinger) (1996-04-04)
Re: Is Fortran90 LL(1)? mjohnson@samson.tx.hac.com (1996-04-08)
Is Fortran90 LL(1)? dave@occl-cam.demon.co.uk (Dave Lloyd) (1996-04-08)
Re: Is Fortran90 LL(1)? dlmoore@ix.netcom.com (1996-04-16)
Re: Is Fortran90 LL(1)? Robert.Corbett@Eng.Sun.COM (1996-04-18)
| List of all articles for this month |
From: mjohnson@samson.tx.hac.com (Mark Johnson)
Newsgroups: comp.compilers
Date: 8 Apr 1996 15:49:50 -0400
Organization: Hughes Training, Inc.
References: 96-04-024
Keywords: Fortran

Christian Rutzinger <rutzinger@takefive.co.at> 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
and
                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 read_statement(line)
    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
--
-- Mark Johnson <mjohnson@samson.tx.hac.com>
[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]


--


Post a followup to this message

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