Venus Probe lost to Fortran - *NOT*
Jim Giles
This story is not a valid objection to Fortran for several reasons.
But first, a recap of the story:
It is claimed that a Venus probe was lost due to a programming error
in which a line was written something like
DO 10 I = 1.10
instead of the intended
DO 10 I = 1,10
The first thing to say is that this is just false. A probe *was* lost due
to a programming error, but this wasn't the error. Indeed, the program
in question was not even written in Fortran. Further, the specific error
was in transcribing handwritten data into the code - not a fault of the
language used or the programmer involved.
Secondly, the DO loop error in question is unlikely to occur in any
real Fortran code simply because almost no loops are have purely
literal bounds. Loops almost always have a variable as either their
lower or upper bound - or both.
Finally, it's not a valid objection to Fortran because it is possible to
make a single character error in *ALL* programming languages.
In fact, it is one of the most common varieties of error in programming.
For example, in C you might have
if (i=5) ...
when you intended
if (i==5)...
Both programs would be legal C yet they do considerably different
things. Or, still in C, you might say
*a = *b/*c;
when you intended
*a = *b/ *c;
The first of these may or may not result in a valid C program (depending
on where the next comment ends), but if valid, will certainly result in
different behavior than intended. I could go on all night with examples
drawn from C alone - but I could go on all night with examples drawn
from *any* of the several dozen languages I'm familiar with.
It is simply not a valid criticism of any given language to point out the
possibility of a single character error. All languages are susceptible to
that kind of fault. The only way to avoid it is to have a language which
requires everything to be written redundantly (at least twice) in
completely
different syntaxes and for the compiler to compare the multiple versions
for consistency. Of course, you'd still have cases where *two* errors
resulted in a valid, but wrong, program.
It seems to be a pandemic flaw of the net that vitriolic language wars are
continually waged. But, it's really silly to use urban myths and spurious
claims to further fuel these wars.
Cheers
Rich R Car
: it did not cause any loss of a vehicle. It was found after MUCH painful
: debugging.
As I remember, the source of this urban myth was an ephemeris program
which (again, if memory serves) was written at the US Naval Observatory.
It shouldn't have involved much debugging effort (if any at all) since
Fortran cross reference maps have, for as long as I remember, included
warnings about variables which have been assigned but never used. Since
one should never run a code with outstanding warning errors against it,
at least not without explicitly determining the cause of each, it should
not have really caused any problems.
Cheers.
Mitchell R Grunes
>>This story is not a valid objection to Fortran for several reasons.
>>But first, a recap of the story:
>>
>>It is claimed that a Venus probe was lost due to a programming error
>>in which a line was written something like
>> DO 10 I = 1.10
>>instead of the intended
>> DO 10 I = 1,10
Maybe the problem did not really occur in that specific incident.
But it easily could have.
A few "good" fortran compilers have warned about identifier (e.g.,
variable, function...) names which have embedded blanks or new-lines
in the source code. It may be legal fortran, but few would deliberately
use it. So compilers should warn of such things.
One book I have says that F90, when accepting "free format",
would complain, because you aren't allowed to have embedded
blanks.
In either case, this is a clear case of something a good compiler
would have helped with. The presence of second rate compilers
should not be taken as a sign the language is no good, although
a good standard which requires the warnings can certainly help.
In any event, I think that most objective individuals would conclude
that any good scientific programmer should be reasonably fluent in
Fortran, C, and at least one decent interactive graphics and scientific
function package (IDL, PV-Wave, MATLAB, Mathematica, AVS, Khoros,
etc.). You can't efficiently do it all in any one language at this
time, given both what is practical and what prior code is available.
I suppose some colleges and universities might feel that would
require too much time, but anyone who gets a scientific or engineering
job is likely to immediately need at least that. I may hate C, but
I still have to use it too.
-------------------------------------------------------------------------
(opinions expressed are mine alone)
Mitchell R Grunes (gru...@nrlvax.nrl.navy.mil)
Allied-Signal Tech. Serv. / Naval Research Lab
Mitchell R Grunes
> >My question: why was ignoring spaces considered such a bright idea by
> >the designer(s) of the FORTRAN language? Without this misfeature,
> >which doesn't bring you any advantage, the defective DO statement would
> >have been easily caught, even with the implicit typing system.
>I've seen FORTRAN code that seemed to use spaces to gain some
>readability in simple variable identifiers, but I never thought
>that it improved it much...
Well, I have heard of people writing lines something like
Variable X in Equation 15 on Page 5 of Reference 12 =
& sqrt( Variable Y in Equation 23 on Page 4 of Reference 18 )
but that doesn't happen to be my personal style.
(I was told of such style in reference to the hazards of using
long variable names with some compilers.)
Dan Pop
>bur...@gnu.ai.mit.edu (Craig Burley) writes:
>
> >I've heard it said (probably here) that it was because there was a
> >huge contingent of keypunch machines around at the time that
> >would accidentally skip a column while punching, and it was felt
> >better to design a language that ignored such "errors" than one that
> >caught them, at the significant cost of a large turnaround time (submit
> >your deck today, get the output tomorrow...).
>
> >Having used keypunch machines for programming as early as, I think,
> >1974 or 75, they seemed generally more solid than the above story
> >would suggest, but the less-than-perfectly-maintained machines did
> >indeed have certain behaviors that could usually be predicted
> >overall, and I imagine that, 20 or so years earlier, accidental
> >"punching" of spaces (skipping columns) could in fact have been a
> >frequent source of user error, which Fortran could advertise as
> >having "fixed" in its own, bizarre way.
>
>This is not consistent with FORTRAN's absolute requirement that exactly
>column 6 be used for the continuation indicator. If the machines were
>unreliable, then they's have put more thought into something like a
>trailing indicator, as is used in C's macro definitions.
Well, they did it, 30 years later, when they designed the free source
format for Fortran 90. But at the same time they made spaces significant,
defeating the original goal of supporting buggy keypunch machines :-)
Mieux vaut tard que jamais.
Dan
--
Dan Pop
CERN, CN Division
Email: dan...@cernapo.cern.ch
Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
Jean-Paul N. Nicol
>Once again the false apocryphal story of the DO loop has cropped up.
>This story is not a valid objection to Fortran for several reasons.
>But first, a recap of the story:
>
>It is claimed that a Venus probe was lost due to a programming error
>in which a line was written something like
> DO 10 I = 1.10
>instead of the intended
> DO 10 I = 1,10
>
>The first thing to say is that this is just false. A probe *was* lost due
>to a programming error, but this wasn't the error. Indeed, the program
>in question was not even written in Fortran. Further, the specific error
>was in transcribing handwritten data into the code - not a fault of the
>language used or the programmer involved.
>
>Secondly, the DO loop error in question is unlikely to occur in any
>real Fortran code simply because almost no loops are have purely
>literal bounds. Loops almost always have a variable as either their
>lower or upper bound - or both.
Well, this error DID actually occur in some NASA code, though, as you say,
it did not cause any loss of a vehicle. It was found after MUCH painful
debugging.
I use it in my classes to illustrate the virtues of explicit typing
(and the use of "IMPLICIT NONE") in all FORTRAN coding, which would
cause the compiler to flag errors such as this.
JP Nicol
Craig Burley
My question: why was ignoring spaces considered such a bright idea by
the designer(s) of the FORTRAN language? Without this misfeature,
which doesn't bring you any advantage, the defective DO statement would
have been easily caught, even with the implicit typing system.
I've heard it said (probably here) that it was because there was a
huge contingent of keypunch machines around at the time that
would accidentally skip a column while punching, and it was felt
better to design a language that ignored such "errors" than one that
caught them, at the significant cost of a large turnaround time (submit
your deck today, get the output tomorrow...).
Having used keypunch machines for programming as early as, I think,
1974 or 75, they seemed generally more solid than the above story
would suggest, but the less-than-perfectly-maintained machines did
indeed have certain behaviors that could usually be predicted
overall, and I imagine that, 20 or so years earlier, accidental
"punching" of spaces (skipping columns) could in fact have been a
frequent source of user error, which Fortran could advertise as
having "fixed" in its own, bizarre way.
It sounds silly now, I know, but look at all the arguments over whether
implicit typing is a feature or misfeature -- would there be any
debate about it 20 years in the future when "everyone" has much
more advanced coding tools at their disposal? I doubt it. I won't
see which way the "debate" will have gone, because I suspect there
will still be some sort of implicit typing offered the user at the
input level at least, even if the action of that system is to display
an explicit type for the user and the underlying compilation system
to deal with.
(Similarly, had there been prototypes and the kind of editing tools
we have today back when C was designed, I doubt there'd be implicit
typing of functions as "int"...etc.)
--
James Craig Burley, Software Craftsperson bur...@gnu.ai.mit.edu
Kenneth Plotkin
Craig Burley <bur...@gnu.ai.mit.edu> wrote:
>I've heard it said (probably here) that it was because there was a
>huge contingent of keypunch machines around at the time that
>would accidentally skip a column while punching, and it was felt
>better to design a language that ignored such "errors" than one that
>caught them, at the significant cost of a large turnaround time (submit
>your deck today, get the output tomorrow...).
[snip]
>Having used keypunch machines for programming as early as, I think,
>1974 or 75, they seemed generally more solid than the above story
>would suggest, but the less-than-perfectly-maintained machines did
[snip]
I put in lots of time keypunching about 10 years earlier, and never
encountered a problem with skipped columns. I always thought that the
idea was that spaces were just ignored, other than in Hollerith (we're
talking 1960s) fields. They were not needed for parsing a line, since
everything in a FORTRAN statement has a specific delimiter - an operator,
parenthesis, whatever. It was a good idea to allow spaces, since
something like A = B + C could be more readable (or at least
eye-pleasing) than A=B+C. Allowing spaces sometimes (between things) and
not others (within things) would have required the compiler to go back
and forth a bit to see if a space was allowed or not. Holleriths were
interpreted on one forward pass because they had the count right up
front. (It was the programmer who had to go back and forth to get the
count!)
Ken Plotkin
Mike Bandy
>My question: why was ignoring spaces considered such a bright idea by
>the designer(s) of the FORTRAN language? Without this misfeature,
>which doesn't bring you any advantage, the defective DO statement would
>have been easily caught, even with the implicit typing system.
They taught me in compiler class that the FORTRAN parser worked by
first removing all of the spaces in a line. Then the line was parsed
out. I remember also that the operator precedence was taken care of
by replacing operators with parenthesises phrases. Something like:
3+4*1 gets changed to (3)+(4*1) where the + is replaced with )+( and
enough parens are stuck on each end to match. With the expression
completely parenthsised the parsing of the expression is fairly trivial.
Remember, FORTRAN was the first high level language so they were still
figuring out all this stuff; I think they had a lot of clever solutions.
So - somebody tell us the actual story about the botched DO statement...
--
Mike Bandy ba...@aplcomm.jhuapl.edu
Johns Hopkins University / Applied Physics Laboratory
Dean P. McCullough
Mitchell R Grunes <gru...@news.nrl.navy.mil> wrote:
>In article <3j5t5q$7...@pssparc2.oc.com> l...@pssparc2.oc.com (Larry Weiss) writes:
>> >My question: why was ignoring spaces considered such a bright idea by
>> >the designer(s) of the FORTRAN language? Without this misfeature,
>> >which doesn't bring you any advantage, the defective DO statement would
>> >have been easily caught, even with the implicit typing system.
>
>>I've seen FORTRAN code that seemed to use spaces to gain some
>>readability in simple variable identifiers, but I never thought
>>that it improved it much...
>
>Well, I have heard of people writing lines something like
>
> Variable X in Equation 15 on Page 5 of Reference 12 =
> & sqrt( Variable Y in Equation 23 on Page 4 of Reference 18 )
>
>but that doesn't happen to be my personal style.
>
I have seen and made use of this feature in large constants, such as:
i = 10 000 000
Without this, it is not easy to distinguish between this and 1 000 000.
--
Dean P McCullough dpm...@zombie.ncsc.mil
Dan Pop
>>>Once again the false apocryphal story of the DO loop has cropped up.
>>>This story is not a valid objection to Fortran for several reasons.
>>>But first, a recap of the story:
>>>
>>>It is claimed that a Venus probe was lost due to a programming error
>>>in which a line was written something like
>>> DO 10 I = 1.10
>>>instead of the intended
>>> DO 10 I = 1,10
>
>Maybe the problem did not really occur in that specific incident.
It didn't in that incident, but it did occur, at the same epoch.
>But it easily could have.
>
>A few "good" fortran compilers have warned about identifier (e.g.,
>variable, function...) names which have embedded blanks or new-lines
>in the source code. It may be legal fortran, but few would deliberately
>use it. So compilers should warn of such things.
Either the state of the art of the 1963 compilers didn't allow them to
spend time trying to catch potential programmer errors, or the
programmer was particularly sloppy and didn't pay any attention to the
compiler diagnostics. But I won't buy the latter alternative.
The fact remains: The offending statement is legal in any Fortran
flavour, including F90 in fixed format mode and a compiler isn't required
to complain about it.
My question: why was ignoring spaces considered such a bright idea by
the designer(s) of the FORTRAN language? Without this misfeature,
which doesn't bring you any advantage, the defective DO statement would
have been easily caught, even with the implicit typing system.
Dan
Thomas Koenig
article <danpop.794259485@rscernix>:
>Well, they did it, 30 years later, when they designed the free source
>format for Fortran 90. But at the same time they made spaces significant,
>defeating the original goal of supporting buggy keypunch machines :-)
Well, this will break one of my habits... I usually call my programs
PROGRAMME MAIN
:-)
--
Thomas Koenig, Thomas...@ciw.uni-karlsruhe.de, ig...@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.
Larry Weiss
>My question: why was ignoring spaces considered such a bright idea by
>the designer(s) of the FORTRAN language? Without this misfeature,
>which doesn't bring you any advantage, the defective DO statement would
>have been easily caught, even with the implicit typing system.
I've seen FORTRAN code that seemed to use spaces to gain some
readability in simple variable identifiers, but I never thought
that it improved it much. FORTRAN on the older machines had
only uppercase alphabet, so you couldn't use naming conventions
like C allows. I never liked the lack of readability that resulted
from N CATS being the same syntactically as NCATS in FORTRAN,
so I never intentionally exploited embedded spaces myself.
--
Larry Weiss, l...@oc.com
214/888-0471
Craig Burley
bur...@gnu.ai.mit.edu (Craig Burley) writes:
>I've heard it said (probably here) that it was because there was a
>huge contingent of keypunch machines around at the time that
>would accidentally skip a column while punching, and it was felt
>better to design a language that ignored such "errors" than one that
>caught them, at the significant cost of a large turnaround time (submit
>your deck today, get the output tomorrow...).
>Having used keypunch machines for programming as early as, I think,
>1974 or 75, they seemed generally more solid than the above story
>would suggest, but the less-than-perfectly-maintained machines did
>indeed have certain behaviors that could usually be predicted
>overall, and I imagine that, 20 or so years earlier, accidental
>"punching" of spaces (skipping columns) could in fact have been a
>frequent source of user error, which Fortran could advertise as
>having "fixed" in its own, bizarre way.
This is not consistent with FORTRAN's absolute requirement that exactly
column 6 be used for the continuation indicator. If the machines were
unreliable, then they's have put more thought into something like a
trailing indicator, as is used in C's macro definitions.
Agreed, but then, I didn't say the claim was that _all_ spaces should
be ignored!
Having actually used keypunches, I imagine a trailing indicator wouldn't
be as practically attractive, upon suddenly approaching col 72 while
punching, as the guaranteed ability to start the next card by punching
an X in column 6.
And, back in the '60s-'70s, and almost certainly therefore in the '50s,
keypunch "forms" were all the rage. I'm sure I still have a bunch
somewhere. Even _today_ we see people post on c.l.f claims that they
find searching for Fortran label definitions easier than in other
supposedly "modern" languages because they know they can find them
in cols 1-5. I'm sure continuation technology was considered part
of this "ease-of-use' factor back in the '50s, in that it was important
to "easily" spot continued vs. initial lines in a statement.
But the best reason for not having a trailing indicator is probably
a _real_ reason: card-reader software needed to know how many cards
to read in _exactly_, without knowing the input language. The
Fortran language, throughout its fixed-form history (though F90
has "broken" this slightly, as I recall), has had the characteristic
that its program units can be read mechanically up through, and no
further than, the final "card" (the END statement) without having
to parse the content in any significantly challenging way. A trailing
indicator wouldn't generally allow for this, especially given the
limited character sets of the day. The Fortran design makes reading
in just the cards needed for a particular program (later, program
unit, when subroutines/functions were added) quite easy compared to,
say, doing so for a language, or F90's free-form input.
Dan Pop
>But the best reason for not having a trailing indicator is probably
>a _real_ reason: card-reader software needed to know how many cards
>to read in _exactly_, without knowing the input language. The
>Fortran language, throughout its fixed-form history (though F90
>has "broken" this slightly, as I recall), has had the characteristic
>that its program units can be read mechanically up through, and no
>further than, the final "card" (the END statement) without having
>to parse the content in any significantly challenging way. A trailing
>indicator wouldn't generally allow for this, especially given the
>limited character sets of the day. The Fortran design makes reading
>in just the cards needed for a particular program (later, program
>unit, when subroutines/functions were added) quite easy compared to,
>say, doing so for a language, or F90's free-form input.
It wasn't that easy since the END statement can be legally written in
fixed format like this:
E
X N
X
X D
Larry Weiss
>I've heard it said (probably here) that it was because there was a
>huge contingent of keypunch machines around at the time that
>would accidentally skip a column while punching, and it was felt
>better to design a language that ignored such "errors" than one that
>caught them, at the significant cost of a large turnaround time (submit
>your deck today, get the output tomorrow...).
>Having used keypunch machines for programming as early as, I think,
>1974 or 75, they seemed generally more solid than the above story
>would suggest, but the less-than-perfectly-maintained machines did
>indeed have certain behaviors that could usually be predicted
>overall, and I imagine that, 20 or so years earlier, accidental
>"punching" of spaces (skipping columns) could in fact have been a
>frequent source of user error, which Fortran could advertise as
>having "fixed" in its own, bizarre way.
This is not consistent with FORTRAN's absolute requirement that exactly
column 6 be used for the continuation indicator. If the machines were
unreliable, then they's have put more thought into something like a
trailing indicator, as is used in C's macro definitions.
--
Larry Weiss, l...@oc.com
214/888-0471
Ron Sverdlove x2517
>
>It wasn't that easy since the END statement can be legally written in
>fixed format like this:
>
> E
> X N
> X
> X D
>
>Dan
>--
>Dan Pop
>CERN, CN Division
>Email: dan...@cernapo.cern.ch
>Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
No. The Fortran 77 standard says in section 11.14, "An END statement is written
only in columns 7 through 72 of an initial line. An END statement must not be
continued. N other statement in a program unit may have an initial line that
appears to be an END statement." The same applies to fixed-form source in
Fortran 90. I think earlier (pre-77) versions of Fortran also restricted the
END statment in this way.
--
Ronald Sverdlove Computational Science Research
r...@sarnoff.com David Sarnoff Research Center
Tel. 609-734-2517 CN 5300
FAX 609-734-2662 Princeton, NJ 08543-5300
bw...@ibm.net
>In article <3j7kr8$e...@pssparc2.oc.com> l...@pssparc2.oc.com (Larry Weiss) writes:
> This is not consistent with FORTRAN's absolute requirement that exactly
> column 6 be used for the continuation indicator. If the machines were
> unreliable, then they's have put more thought into something like a
> trailing indicator, as is used in C's macro definitions.
Of course, the allowing of spaces, was, IMHO, not nearly as pernicious as the tendency
of some compilers to just IGNORE characters in columns 73 through 80, so they could be
used (I was told -- never did it) for sequence numbers, in case the deck was dropped.
Conveniently, the compiler I used at the time printed whatever was there, making the task
of actually seeing this error even more maddening.
Craig Burley
It wasn't that easy since the END statement can be legally written in
fixed format like this:
E
X N
X
X D
Does anyone know for sure whether this was true about original FORTRAN?
I haven't been around long enough to even know whether continuation
lines themselves were part of the original language design.
But, it seems you recognize something that others might not pick up,
that in F77 and even F90, it is _not_ valid to write an assignment
statement this way:
END
&=BEGIN
This could be viewed as the One Reserved Word in all of FORTRAN, in the
limited sense that you could write the above assignment that way if
the destination was anything other than "END", etc.
Since the reasoning behind mandating that any line with the word
"END" alone on it must therefore be an END statement, regardless
of any possible following continuation lines, seems to have been
to make it easy for card-reader spoolers to know when the input
program was fully read, I wouldn't be surprised to find that
either:
- END as a single, uncontinued statement was the only way to
"legally" (validly) end a program in original Fortran
- Even if one could continue E N D across several lines, in practice
and/or perhaps by mandate, at least some card-reader spoolers didn't
bother accommodating such methods
(I do hope I can dig up my ancient Fortran II tutorial book, but I
have an awful feeling it, along with much other stuff like old PDP-1
reference manuals, were lost in moves I've done since '77.)
H Richardson
>
>
> It is claimed that a Venus probe was lost due to a programming error
> in which a line was written something like
> DO 10 I = 1.10
> instead of the intended
> DO 10 I = 1,10
>
>
> Secondly, the DO loop error in question is unlikely to occur in any
> real Fortran code simply because almost no loops are have purely
> literal bounds. Loops almost always have a variable as either their
> lower or upper bound - or both.
>
This is not the point, the statement would not be interpreted as a DO loop
and that is the problem - think about it.
Using the form
DO 10, I=1,10
would allow a compiler to catch the mistake above but not many people
use this form of the DO loop.
Other than that, you make some good points.
Harvey
Larry Weiss
>I have seen and made use of this feature in large constants, such as:
> i = 10 000 000
>Without this, it is not easy to distinguish between this and 1 000 000.
With the new preprocessor operator ## in Standard C you can code:
#include <stdio.h>
#define I(a,b,c) a##b##c
main()
{
int i;
i = I( 10,000,000 );
printf("%10d\n", i);
}
and other variations on the theme.
Dan Pop
>In article <3ip714$i...@newsbf02.news.aol.com>, jimg...@aol.com (Jim Giles) writes:
>>...
>>
>>
>> It is claimed that a Venus probe was lost due to a programming error
>> in which a line was written something like
>> DO 10 I = 1.10
>> instead of the intended
>> DO 10 I = 1,10
>>
>> ...
>>
>> Secondly, the DO loop error in question is unlikely to occur in any
>> real Fortran code simply because almost no loops are have purely
>> literal bounds. Loops almost always have a variable as either their
>> lower or upper bound - or both.
>>
The one which caused headaches at NASA in 1963 didn't.
>
>This is not the point, the statement would not be interpreted as a DO loop
>and that is the problem - think about it.
>
>Using the form
>
> DO 10, I=1,10
>
>would allow a compiler to catch the mistake above but not many people
>use this form of the DO loop.
And virtually nobody used this syntax in 1963, because it was invented
much later.
Kurt Kallblad
Burley, Software Craftsperson, bur...@gnu.ai.mit.edu says...
>
>In article <danpop.794446207@rscernix> dan...@cernapo.cern.ch (Dan Pop)
writes:
>
> It wasn't that easy since the END statement can be legally written in
> fixed format like this:
>
> E
> X N
> X
> X D
>
>Does anyone know for sure whether this was true about original FORTRAN?
>I haven't been around long enough to even know whether continuation
>lines themselves were part of the original language design.
************
I don't think the above is legally written as the F77 standard (11.14) says:
"An END statement is written only in colomn 7 through 72 of an initial line.
An END statemant must not be continued."
But at least MS Fortran 5.x allows the above way of writing the END
statement.
I don't remember what F66 standard had to say about the END statement but
I'm sure that continuation lines was allowed in other statments. But then,
F66 might not be called the original language design.
************
>
>But, it seems you recognize something that others might not pick up,
>that in F77 and even F90, it is _not_ valid to write an assignment
>statement this way:
>
> END
> &=BEGIN
>
>This could be viewed as the One Reserved Word in all of FORTRAN, in the
>limited sense that you could write the above assignment that way if
>the destination was anything other than "END", etc.
>
>Since the reasoning behind mandating that any line with the word
>"END" alone on it must therefore be an END statement, regardless
>of any possible following continuation lines, seems to have been
>to make it easy for card-reader spoolers to know when the input
>program was fully read, I wouldn't be surprised to find that
>either:
>
>- END as a single, uncontinued statement was the only way to
> "legally" (validly) end a program in original Fortran
>
>- Even if one could continue E N D across several lines, in practice
> and/or perhaps by mandate, at least some card-reader spoolers didn't
> bother accommodating such methods
>
>(I do hope I can dig up my ancient Fortran II tutorial book, but I
>have an awful feeling it, along with much other stuff like old PDP-1
>reference manuals, were lost in moves I've done since '77.)
>--
************
As the F77 standard doesn't allows continuation lines for an END statement,
the lines above is IMO an assignment statement and not an END statement. At
least MS Fortran 5.x treats it that way and I have not seen a word about END
as a reserved word in any of my VAX, IBM or Univac manuals. But I might have
missed it and I don't know if F90 has reserved words.
My old F66 manuals are lost and my oldest saved manual is from 1979. But I
found an older card deck used on Univac. The card-readers at that system
used the @ character in the first column to indicate control cards. A
typical card-deck could look like:
@RUN ... account etceteras
@FOR ...
Fortran statements and comments
@XQT
@FIN
All fortran statements was only read in to a file by the card-reader and an
END statement wasn't recordnized. Any control card marked the end of the
Fortran program unit.
BTW, how to treat a deck with subroutines and functions, each ending with an
END statement, if the card-reader ends the program at the first Fortran END
statement?
Have a nice day!
Kurt
--
Kurt Kallblad E-mail: kurt.k...@bkl.lth.se
Department of Building Science Phone: +46 46 107358
Lund Institute of Technology Fax: +46 46 104719
P.O.Box 118, LUND
S-221 00 Sweden
<Speaking for myself, not the department, nor ...>
Michael METCALF
>
>In article <danpop.794446207@rscernix>, Dan Pop <dan...@cernapo.cern.ch>
wrote:
>>It wasn't that easy since the END statement can be legally written in
>>fixed format like this:
>>
>> E
>> X N
>> X
>> X D
>
>subset and full language state that the END statement has to be all
>on the initial line and you're not allowed to have an initial line of
>another kind of statement that looks like an END. Don't know about
>earlier standards, but I wouldn't think that the people on the
>'77 comittee would think this up for no reason.
>--
Neither McCracken nor Organic, in their 1962 books, mention any
restriction on the form of the END statement, but their descriptions
strongly imply that it is expected to appear on one line.
The FORTRAN 66 standard, the first ever for any programming language
states: "An end line is a line with the characters E, N, and D, once
each and in that order, in columns 7 through 72, preceded by or
interspersed by the character blank". This restriction appears in
FORTRAN 77 and Fortran 90 too, in different words. This means
that the sequence
end
&=begin
must be interpreted as the end of a procedure followed by an
unexpected continuation line at the beginning of a main program.
Mike Metcalf
(met...@cern.ch)
Craig Burley
BTW, how to treat a deck with subroutines and functions, each ending with an
END statement, if the card-reader ends the program at the first Fortran END
statement?
Easy, just don't allow anything other than a main program unit. Just
like original FORTRAN. :-)
Rich R Car
: > ...
: >
: > Secondly, the DO loop error in question is unlikely to occur in any
: > real Fortran code simply because almost no loops are have purely
: > literal bounds. Loops almost always have a variable as either their
: > lower or upper bound - or both.
: This is not the point, the statement would not be interpreted as a DO loop
: and that is the problem - think about it.
Actually, that is the point. If I never write:
DO 10 I=1,10
But I always write:
DO 10 I=1,N
Then accidentally replacing the comma with a period will never result in
any inadvertant "correct" program. That is, the mistake will always simply
generate a syntax error. (In this case, the error will probably say something
like "syntax error in assignment statement", and point to what you thought
was a DO statement, but you can still easily see the error).
Cheers
Brian Stecher
>fixed format like this:
>
> E
> X N
> X
> X D
Not in FORTRAN 77 you couldn't. Section 3.3 (page 3-3) of both the
subset and full language state that the END statement has to be all
on the initial line and you're not allowed to have an initial line of
another kind of statement that looks like an END. Don't know about
earlier standards, but I wouldn't think that the people on the
'77 comittee would think this up for no reason.
--
Opinions expressed herein are strictly | Brian Stecher
those caused by the caffeine from many | br...@watcom.on.ca
cans of Coca-Cola. | Watcom International Corporation
Kurt Kallblad
>As the F77 standard doesn't allows continuation lines for an END statement,
>the lines above is IMO an assignment statement and not an END statement. At
>least MS Fortran 5.x treats it that way .....
SORRY, I missed a line in the standard. "No other statement in a program
unit may have an initial line that appears to be an END statment"
I didn't use the strict checking in MS Fortran when I checked it.
Ron Sverdlove
>
>Neither McCracken nor Organic, in their 1962 books, mention any
>restriction on the form of the END statement, but their descriptions
>strongly imply that it is expected to appear on one line.
>The FORTRAN 66 standard, the first ever for any programming language
>states: "An end line is a line with the characters E, N, and D, once
>each and in that order, in columns 7 through 72, preceded by or
>interspersed by the character blank". This restriction appears in
>FORTRAN 77 and Fortran 90 too, in different words. This means
>that the sequence
>
> end
> &=begin
>
>must be interpreted as the end of a procedure followed by an
>unexpected continuation line at the beginning of a main program.
>
> Mike Metcalf
> (met...@cern.ch)
>
I have an IBM Fortran II for 7090/7094 manual with copyright dates
1958-63. The END statement there has the form:
END (I1,I2,I3,I4,I5)
where the five integers are sense switch settings. It is not clear whether
they are required or optional. It does say that the END statement itself
is optional in a deck that consists of only one program unit, but that it
is required as a separator in decks containing multiple program units.
There is no explicit restriction on continuation of the statement.
Kenneth Plotkin
> END statement, if the card-reader ends the program at the first Fortran END
> statement?
I don't think the card reader interprets the END. Somebody mentioned
@... cards on one system. Card decks always contain control cards which
delimit different sections. On the IBM 7040 I used in the '60s, they had
$ in column 1. Ones that I remember were $JOB, $IBREL, $DATA, $END,
$IBSYS. $END ended your entire deck, and $IBSYS turned control over to
the system - that had to be the last card in the computer center at my
school. $IBREL (I'm not 100% sure of the spelling) was used to mark the
end of the source to be compiled and the beginning of object decks which
were punched by the system on a previous run.
Having a deck with several routines, each ending with END, is exactly
analogous to the current method of having a file which might have several
routines. The EOF marker tells the system to stop looking, just like
the control cards used to.
Ken Plotkin
Jim Davies
>With the new preprocessor operator ## in Standard C you can code:
>#define I(a,b,c) a##b##c
> i = I( 10,000,000 );
Which works if you have a number greater than 1 million. But pity the
poor maintenance programmer who sees this, thinks "cool!", and decides
to use it for a smaller number:
j = I (0,123,000);
Oops!