ambiguous ?

Jim Giles jlg at lanl.gov
Mon Oct 23 13:39:43 AEST 1989


>From article <6613 at ficc.uu.net>, by peter at ficc.uu.net (Peter da Silva):
> [ in Fortran,
> 	CALL SUBR(FUNC, FUNC)
> May be called as
> 	TEMP=FUNC
> 	CALL SUBR(TEMP, TEMP)
> So, FORTRAN does have ambiguous and unspecified behaviour. It just
> describes it in different terms. If Jim Giles has a problem with C,
> then he must have an even bigger problem with FORTRAN. If not, then
> his opposition to C must be based on religious beliefs rather than
> logical reasoning.

Propagating false information is not a very useful way to
discuss any issue.  As I've already pointed out, the first
call given above is _illegal_ in Fortran if the order (or
number) of function evaluations will effect the meaning of
the program (that is, if FUNC has side-effects).  As I've
already said, I consider this to be over-restriction in the
same way that C is under-restricted.  As I've already said,
the solution I favor is to provide the user _explicit_ means
of specifying whether a function has side-effects and then
allowing the compiler to optimize _NON_SIDE-EFFECT_ function
calls in any way it likes.  Meanwhile, the language _should_
have consistent rules about the order of calling functions
that _DO_ have side-effects.

Meanwhile, the given example does NOT demonstrate "ambiguous
and unspecified behaviour" in Fortran.  If the first statement
is _legal_ then the optimization represented here has _exactly_
the same meaning.



More information about the Comp.lang.c mailing list