mcdonald@uxe.cso.uiuc.edu (10/18/87)
>/* Written 2:04 pm Oct 16, 1987 by naparst@cartan.Berkeley.EDU in uxe.cso.uiuc.edu:comp.lang.fortran */ >/* ---------- "Value parameters" ---------- */ >According to the fortran standard, value parameters must not be modified. >Why does the following program, then, give the output x=1, when it should >bomb in sub() ? This is f77 on 4.3. > > x = 1 > call sub(x + 7) > print *,x > stop > end > > subroutine sub(x) > x = 2 > return > end > >Harold Naparst (naparst@cartan.berkeley.edu or ucbvax!cartan!naparst) >-- >Harold Naparst (415)-848-4560 > UUCP {tektronix,dual,sun,ihnp4,decvax}!ucbvax!cartan!naparst > New style naparst@cartan.berkeley.edu > ARPA | CSNET naparst%cartan@berkeley.ARPA >/* End of text from uxe.cso.uiuc.edu:comp.lang.fortran */ Although Kurt Hirschert, U of I's resident F8X committee member give the correct (and definitive) answer to this whole discussion, I'm going to try one more time to explain it. The Fortran standards, both present and yet unborn, define in their own inimitable jargon what result a compliant compiler MUST produce for a compliant program. They do NOT define what a compiler must do for ALL programs which do not fit the standards. They do define certain instances of erroneous programs which a compiler must flag, but in certain cases compliant compilers are allowed to pass through things which are not completely defined (Kurt, is this true?). In those cases where the standard is mute, THE EXACT COMPILER YOU USE DEFINES THE "correct" RESULT. The standard says "If you, the program writer, pass an expression to a subroutine, I (ANSI) expect YOU not to modify that in the subroutine. If you *do* modify it, the compiler may tell you something or may not, in any case it (the compiler) DEFINES the action taken." Your example main program is a perfectly good Fortran program. The subroutine is a perfectly good subroutine. HOWEVER, according to the standards, THAT main program calling THAT subroutine is not 100% compliant (i.e. defined by the standard to to a particular thing). (Actually I'm not so sure about the print statement, but that's beside the point.) Fortran is VERY loose in forcing compilers (and linkers!) to examine subroutine linkage. It put responsibility on the programmer. Among other things, that allows wide latitude in doing tricky and useful things. Just be thankful that noone, to date, has written a compiler that detects such things and decides to dump you into Rogue! Doug McDonald
hirchert@uxe.cso.uiuc.edu (10/24/87)
/* Written 5:20 pm Oct 18, 1987 by c9c-ra@dorothy.Berkeley.EDU in uxe.cso.uiuc.edu:comp.lang.fortran */
In article <7370@alice.UUCP> ark@alice.UUCP writes:
...
TOO MANY LAWYERS around reading between the lines of every document and
displaying petty arguments about what iss there between the lines.
The point should be defined as:
1)Compilers should support standard FORTRAN77
2)They should do something about illegal syntax or
invalid operations. There were sevaral postings
about f77 which doesn't do anything about some
VERY OBVIOUS errors such as not assigning a value
to a function name or misinterpreting continuation line
(both of them were posted earlier) **PUNCHLINE?
RESERVED WORDS ARE NEEDED ***
3) WATFOR77 DOES AN EXCELLENT JOB about catching illegal usage
of FORTRAN. IF ONLY you could learn from WATERLOO people.
4)FORTRAN encourages the programmers BEING LAZY. You can
slap together a FORTRAN program and it does not look as bad
as a 'badly-written-Pascal program'. Because FORTRAN LACKS
structures.
METHINKS IT IS THE TIME TO INTRODUCE STRUCTURES SUCH AS WHILE OR
REPEAT-UNTIL etc. LIKE WATFOR77 DOES or see that the language
is taking its place (Slowly) in bit heaven where it belongs.
(Where are the 8X people?)
...
Akin Ozselcuk
/* End of text from uxe.cso.uiuc.edu:comp.lang.fortran */
Instead of legal programs or compilers, people should be talking about
standard-conforming programs or compilers, but I don't think anyone is mislead
by this short cut in vocabulary. The real point is that the standard places
only minimal requirements on compilers. The primary requirement is that it
correctly handle standard-conforming programs. There is no requirement that it
detect programs that do not conform and there probably never will be. Some
of the requirements on standard-conforming programs cannot reasonably be
enforced. WATFOR77 enforces many of these requirements, but at the cost of an
order of magnitude slowdown relative to FORTRAN G and FORTRAN G can be an order
of magnitude slower than a good compiler. Even so, there are requirements that
WATFOR77 doesn't enforce because the cost of doing so would likely be another
order of magnitude slowdown. In other words, the Fortran standard is designed
to support a fast language, not necessarily a safe one. The restrictions in
it are designed not for enforceability, but to provide the compiler with the
information it needs to efficiently optimize the code it produces.
While reserved words maginally improve error interpretation, they can cause
severe portability problems, especially when the addition of extended features
results in the addition of new reserved words. For toy languages supporting
mostly student programmers who are expected to commit many errors and not
understand them, reserved words are fine, but for programs millions of lines
long with lifetimes measured in decades, they can be a severe problem (unless,
of course, you have the kind of clout DoD had in demanding that there would
be no extended Ada's).
Fortran 77 has structured selection (i.e., the block-IF) but no structured
looping because the committee that produced it was able to reach a quick
consensus on the former but not the latter. The proposed draft for Fortran 8x
does include a structured loop (albeit somewhat different from those offered
by WATFOR77), as well as data structures, recursion, internal procedures,
dynamic storage allocation, and many other features people seem to expect in a
"modern" language. (By the way, the draft of Fortran 8x does include a
requirement that standard-conforming compilers have an option to detect the
syntactic violations of the standard, but the problem that started all this
(modifying a dummy argument corresponding to an expression) is detectable in
the general case only with run-time checks, so Fortran 8x compilers will not
be required to detect it.)
Kurt W. Hirchert
National Center for Supercomputing Applications
and a member of X3J3 (the committee producing Fortran 8x)alan@mn-at1.UUCP (Alan Klietz) (10/26/87)
In article <50500013@uxe.cso.uiuc.edu> hirchert@uxe.cso.uiuc.edu writes:
<
<Instead of legal programs or compilers, people should be talking about
<standard-conforming programs or compilers, but I don't think anyone is mislead
<by this short cut in vocabulary. The real point is that the standard places
<only minimal requirements on compilers. The primary requirement is that it
<correctly handle standard-conforming programs. There is no requirement that it
<detect programs that do not conform and there probably never will be.
Not a requirement? But desirable. A compiler that purports to offer
standardization and portability features must offer an option to issue
warnings about the use of non-standard constructs.
<In other words, the Fortran standard is designed
<to support a fast language, not necessarily a safe one. The restrictions in
<it are designed not for enforceability, but to provide the compiler with the
<information it needs to efficiently optimize the code it produces.
Although not required, a good compiler should offer an option to detect
"unsafe" constructs, even at a loss of runtime speed during the prototype
design phase.
<
<While reserved words maginally improve error interpretation, they can cause
<severe portability problems, especially when the addition of extended features
<results in the addition of new reserved words. For toy languages supporting
<mostly student programmers who are expected to commit many errors and not
<understand them, reserved words are fine, but for programs millions of lines
<long with lifetimes measured in decades, they can be a severe problem (unless,
<of course, you have the kind of clout DoD had in demanding that there would
<be no extended Ada's).
Fortran has no reserved words.
<
<Fortran 77 has structured selection (i.e., the block-IF) but no structured
<looping because the committee that produced it was able to reach a quick
<consensus on the former but not the latter. The proposed draft for Fortran 8x
<does include a structured loop (albeit somewhat different from those offered
<by WATFOR77), as well as data structures, recursion, internal procedures,
<dynamic storage allocation, and many other features people seem to expect in a
<"modern" language.
About time. After what, 30 years?
<(By the way, the draft of Fortran 8x does include a
<requirement that standard-conforming compilers have an option to detect the
<syntactic violations of the standard)
Ah, so it's a requirement after all. Good.
<The problem that started all this, modifying a dummy argument corresponding
<to an expression, is detectable in the general case only with run-time
<checks, so Fortran 8x compilers will not be required to detect it.
An expression is a constant syntactical entity, so it should be possible
to detect the attempt at load time.
<
<Kurt W. Hirchert
-Alan Klietzchris@mimsy.UUCP (10/28/87)
In article <398@mn-at1.UUCP> alan@mn-at1.UUCP (Alan Klietz) writes: ><The problem that started all this, modifying a dummy argument corresponding ><to an expression, is detectable in the general case only with run-time ><checks, so Fortran 8x compilers will not be required to detect it. >An expression is a constant syntactical entity, so it should be possible >to detect the attempt at load time. Not so. Consider the following example: C I cannot stand all caps, so this is all lowercase subroutine sub(x, isexp) real x logical isexp real v C compute something based on x v = ... if (.not. isexp) then C reassign x x = v endif ... end A conformant program will then give `true' for `isexp' whenever the value passed in as `x' is an expression, not a simple variable. (It has been several years since I wrote any Fortran; apologies for any bugs in the example above.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris