Fortran - BNF notation needed

Author

BNF notation needed

GroThar

2006-04-12, 10:01 pm

Hy,
I'm working on a school project and we're writing a translator for
Fortran, so I'm trying to find BNF definition for fortran 66 or 77. So
if anybody knows where to find it I would be very grateful.
Thanks

Michael Metcalf

2006-04-12, 10:01 pm

"GroThar" <grothar@gmail.com> wrote in message
news:e1jn59$lhn$1@sunce.iskon.hr...
> Hy,
> I'm working on a school project and we're writing a translator for
> Fortran, so I'm trying to find BNF definition for fortran 66 or 77. So if
> anybody knows where to find it I would be very grateful.
> Thanks

To the best of my knowledge, it doesn't exist. BNF (with constraints) was
first introduced for Fortran 90.

Regards,

Mike Metcalf

glen herrmannsfeldt

2006-04-12, 10:01 pm

Michael Metcalf <michaelmetcalf@compuserve.com> wrote:
>
> "GroThar" <grothar@gmail.com> wrote in message
> news:e1jn59$lhn$1@sunce.iskon.hr...

[color=darkred]
> To the best of my knowledge, it doesn't exist. BNF (with constraints) was
> first introduced for Fortran 90.

I thought B and N worked on the first Fortran compiler.

Some years ago I used the version in the S/360 Fortran Syntax
Checker manual, but I don't see it on the web so far.
It might not be real BNF but it was close enough. Though it
is for S/360 Fortran, which has some extensions over F66.

There might be one in:

http://www.bitsavers.org/pdf/ibm/36..._To_PL1_PLM.pdf

This might even be before S/360 Fortran. It might also have some
ideas on language translation that might be useful.

-- glen

Brooks Moses

2006-04-12, 10:01 pm

GroThar wrote:
> I'm working on a school project and we're writing a translator for
> Fortran, so I'm trying to find BNF definition for fortran 66 or 77. So
> if anybody knows where to find it I would be very grateful.

It's not Fortran 66 or 77, but you might find the BNF for the F language
(which is a "nice" subset of Fortran 90) to be useful. See the link at
the bottom of this page:
http://www.fortran.com/imagine1/about_f.html

SGI once delivered a manual which contains the complete Fortran 90
syntax in BNF; as Fortran 90 is essentially a superset of Fortran 77,
once should be able to cut it down to a BNF for Fortran 77:
http://techpubs.sgi.com/library/man...07-3694-006.pdf

This purports to be "THE SYNTAX OF DECsystem-10/20 FORTRAN 77 IN
EXTENDED BNF" (which might already contain some of the extensions you
ought to support):
http://pdp-10.trailing-edge.com/for...f72bnf.syn.html

Appendix D of the Fortran 2003 spec (available online in working-draft
form) has the language rules; again, this is largely a superset of
Fortran 77, so you should be able to cut it down to a Fortran-77 BNF.
http://j3-fortran.org/doc/meeting/168/04-007.pdf

Finally, note the slightly ominous note at the bottom of this old post.
I'm not quite sure what the "tokenization problem" referred to is, but
it may be worth thinking about :
http://compilers.iecc.com/comparch/article/96-07-186

This looks like it might shed a little light on that, and on some of teh
complications of parsing Fortran:
http://www.edm2.com/0511/ait.html

I found all that (except the Fortran 2003 spec, which I already knew
about) with about 15 minutes of Google-searching on "bnf 'fortran 77'"
and looking through the first eight pages of results. Hope it helps!

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

Gary L. Scott

2006-04-12, 10:01 pm

Brooks Moses wrote:
> GroThar wrote:
>
>
>
> It's not Fortran 66 or 77, but you might find the BNF for the F language
> (which is a "nice" subset of Fortran 90) to be useful. See the link at
> the bottom of this page:
> http://www.fortran.com/imagine1/about_f.html
>
> SGI once delivered a manual which contains the complete Fortran 90
> syntax in BNF; as Fortran 90 is essentially a superset of Fortran 77,
> once should be able to cut it down to a BNF for Fortran 77:
> http://techpubs.sgi.com/library/man...07-3694-006.pdf
>
>
> This purports to be "THE SYNTAX OF DECsystem-10/20 FORTRAN 77 IN
> EXTENDED BNF" (which might already contain some of the extensions you
> ought to support):
> http://pdp-10.trailing-edge.com/for...f72bnf.syn.html
>
> Appendix D of the Fortran 2003 spec (available online in working-draft
> form) has the language rules; again, this is largely a superset of
> Fortran 77, so you should be able to cut it down to a Fortran-77 BNF.
> http://j3-fortran.org/doc/meeting/168/04-007.pdf
>
> Finally, note the slightly ominous note at the bottom of this old post.
> I'm not quite sure what the "tokenization problem" referred to is, but
> it may be worth thinking about :
> http://compilers.iecc.com/comparch/article/96-07-186
>
> This looks like it might shed a little light on that, and on some of teh
> complications of parsing Fortran:
> http://www.edm2.com/0511/ait.html
>
> I found all that (except the Fortran 2003 spec, which I already knew
> about) with about 15 minutes of Google-searching on "bnf 'fortran 77'"
> and looking through the first eight pages of results. Hope it helps!
>
> - Brooks
>
>
Goodness, that was really going above and beyond the usenet help norm.

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

wclodius@lanl.gov

2006-04-12, 10:01 pm

Brooks Moses wrote:
><snip>
>
> Finally, note the slightly ominous note at the bottom of this old post.
> I'm not quite sure what the "tokenization problem" referred to is, but
> it may be worth thinking about :
> http://compilers.iecc.com/comparch/article/96-07-186

Programs are translated through several stages. The first stage,
lexing, recognizes the basic components of the language (Tokens) and
puts them into categories. These categories normally include language
identified names with special meanings (keywords), user defined names,
string literals, numeric literals, specific punctuation symbols, etc.
The parser uses a grammar that relies on the category associated with
each token to determine the overall structure of the program. You have
a tokenization problem if the natural categories generated by the lexer
do not fit the natural categories required by the parser and its
grammar. In the worst case the grammar can be completely ambiguous. In
many cases the grammar is not truly ambiguous, but the parser
(typically for efficiency reasons) is designed to only accept grammars
which fit into a simpler subset of all grammars. For most languages the
techniques to rewrite grammar into a form acceptable by the available
tools, is straightforward using well known rules.

The published nominal BNFs for Fortran are ambiguous and either cannot
be distinguished at all in a context free grammar, or can only be
distinguished by massive rewrites of the grammar. Few automated tools
deal well with context sensitive grammars. Problems relatively unique
to Fortran include
1. Lack of reserved keywords
2. Similarity of statement functions to assignment to array elements
3. Similarity of function calls and array element access

The first problem is normally (always) handled by a backtracking lexer.
Fortran has special rules on where punctuation (e.g.. "(", ")", "=",
and ",") can appear. There are variants, but the lexer might initially
assume at the start of a statement that it is an assignment. If the
punctuation does not fit this assumption, it then checks if the start
of the statement is a Fortran keyword, if it is the lexer marks it as
the appropriate keyword and continues processing, otherwise it
indicates that a lexical error has occurred, and either stops
processing or makes its best guess of a possible fix and continues
lexing, perhaps generating spurious error messages if its assumed fix
is incorrect..

The second and third problems can be handled by using context to
identify which names are known from earlier context to be arrays (which
have to be explicitly declared early in the procedure, before the
ambiguities can appear). This is easily done in a handwritten recursive
descent parser. In automatic parsers the ambiguity is normally not
resolved, but the grammar input to the parser instead uses something
like statement_function_or_array_name (instead of separately
distinguishing statement _function_name and array_name for ambiguity 2)
and function_or_array_name (instead of function_name or array_name for
ambiguity 3) which is then disambiguated by a simple second pass over
the resulting parse.

> <snip>

Walt Brainerd

2006-04-12, 10:01 pm

GroThar wrote:

> Hy,
> I'm working on a school project and we're writing a translator for
> Fortran, so I'm trying to find BNF definition for fortran 66 or 77. So
> if anybody knows where to find it I would be very grateful.
> Thanks

Appendix F of the Fortran 77 standard contains
"railroad charts" describing the syntax of F77
(I know 'cause I created them myself).

It is sort of equivalent to BNF and you might
find it interesting as an aid for your project.

Unfortunately, Appendix F doesn't appear in either
form of the standard available at fortran.com, but
you might be able to find a printed copy of the
standard somewhere.

--
Walt Brainerd walt@fortran.com
The Fortran Company
6025 N. Wilmot Rd., Tucson, AZ 85750 USA

Walt Brainerd

2006-04-12, 10:01 pm

GroThar

2006-04-13, 4:07 am

Brooks Moses

2006-04-13, 10:03 pm

Gary L. Scott wrote:
> Brooks Moses wrote:
[...]
>
> Goodness, that was really going above and beyond the usenet help norm.

My enthusiasm for what I had planned to be doing that afternoon shows
that strongly, does it? :)

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

Sponsored Links