Related articles |
---|
Re: Programming language and IDE design martin@gkc.org.uk (Martin Ward) (2013-11-16) |
Re: Programming language and IDE design gneuner2@comcast.net (George Neuner) (2013-11-18) |
Re: Programming language and IDE design gneuner2@comcast.net (George Neuner) (2013-11-19) |
Re: Parsing Fortran, was Programming language and IDE design gah@ugcs.caltech.edu (glen herrmannsfeldt) (2013-11-19) |
Re: Parsing Fortran, was Programming language and IDE design gah@ugcs.caltech.edu (glen herrmannsfeldt) (2013-11-21) |
From: | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
Newsgroups: | comp.compilers |
Date: | Thu, 21 Nov 2013 21:22:45 +0000 (UTC) |
Organization: | Aioe.org NNTP Server |
References: | 13-11-016 13-11-018 13-11-021 13-11-024 |
Keywords: | Fortran, parse |
Posted-Date: | 22 Nov 2013 20:31:02 EST |
(snip, I wrote)
> Because of this complication, WATFIV, at least the version I used,
> disallowed 'FORMAT(' as the first seven characters of a statement that
> wasn't a FORMAT statement. That is, no assignment to elements of an
> array named FORMAT. (I believe WATFIV allows multiple assignment, so
> there would have been a way to get around it.)
(snip)
> [I found that H descriptors were easy to handle, just pull them out in a
> prepass. The problem was assignments that look like format statements:
> FORMAT(A5,I3,I5) = 42
> WATFIV was a student compiler and probably concluded that any student
> who wrote code like that deserved to fail. -John]
But arrays named FORMAT are allowed everywhere else, except at the left
side of an assignment. Functions named FORMAT are also allowed.
And at least once, (not with WATFIV) I used it as the name of a run-time
format specified, which was required to be an array.
-- glen
Return to the
comp.compilers page.
Search the
comp.compilers archives again.