Path: utzoo!attcan!uunet!cs.utexas.edu!rutgers!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.c
Subject: Re: ambiguous ?
Message-ID: <14104@lanl.gov>
Date: 23 Oct 89 03:39:43 GMT
References: <6613@ficc.uu.net>
Organization: Los Alamos National Laboratory
Lines: 30

From article <6613@ficc.uu.net>, by peter@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.