······@cse.ucsc.edu (Eugene Miya) writes:
> >We could collect: great errors in programming language design
> >(e.g., GOTOs [or not], the original FORTRAN DO-loop, etc.).
>
> P.S. A whole generation or two of programmers never saw the problems
> with GOTOs. Whole generations of programmers never saw what the problem
> with original DO-loops were (you could never NOT execute a loop without
> resorting to use another branch: always executed one time was considered
> a feature rather than a bug), and other empirically determined lessons.
FORTRAN (the standard) *never* required always executing the loop
once. The '66 standard allowed it, by virtue of not defining what
should happen (it was before my time, and I don't recall whether the
old timers did it to accommodate some existing practice on some
platform or whether it was a simple oversight).
Failure to specify (even with the weasel words "processor dependent")
makes me somewhat inclined to the latter. Certainly it's hard to say
there is evidence the committee ever thought of it as a feature.
All that was from memory. Actually looking at the '77 standard,
appendix B section notes says:
If J1 > J2, ANSI X3.9-1966 does not allow execution of the
following do statement:
DO 100 J=J1,J2
some processors that allowed such a case executed the range of
the DO-loop once, whereas other processors did not execute the
range of the DO-loop. This standard allows such a case and
requires that the processor execute the range of the DO-loop
zero times.
Which I interpret as the later incarnation of the committee pointing
out that *writing* the "one trip do loop" was nonstandard conformant
to begin with.
Hardly evidence of conscious design. It's possible that some
implementors thought it was a "feature" to allow it; but I suspect
that what generally happened is that the "one trip" do fell out of a
particular implementation decision(s) (essentially whether to test at
the top or the bottom of the loop; with some processors favoring the
test at the bottom only for performance reasons), and was eventually
documented when someone (either in support or "techpubs") noticed that
it worked, and needed to explain it to users.
--
Keith H. Bierman ·············@Sun.COM| ···@chiba.Eng.Sun.COM
SunSoft Developer Products | ···@netcom.com
2550 Garcia UMPK16-304 415 786-9296 | (415 7869296) fax
Mountain View, CA 94043 <speaking for myself, not Sun*> Copyright 1996