Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!sugar!ficc!peter
From: peter@ficc.uu.net (Peter da Silva)
Newsgroups: comp.lang.c
Subject: Re: ambiguous ?
Message-ID: <6658@ficc.uu.net>
Date: 24 Oct 89 15:47:24 GMT
References: <6637@ficc.uu.net> <14111@lanl.gov>
Reply-To: peter@ficc.uu.net (Peter da Silva)
Organization: Xenix Support, FICC
Lines: 91

In article <14111@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
> From article <6637@ficc.uu.net>, by peter@ficc.uu.net (Peter da Silva):
> > This has nothing to do with function calls that have side effects. We're
> > talking about evaluation order of arguments... expressions that have side
> > effects being used in arguments to function calls.

> I've already discussed this case in THREE previous submissions!

I know that and you know that. So why don't you go back and read what
you yourself wrote.  It'd certainly not clear:

+---------
! From: jlg@lanl.gov (Jim Giles)
! Newsgroups: comp.lang.c
! Subject: Re: ambiguous ?
! Message-ID: <14104@lanl.gov>
! 
! 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.
+---------

Perhaps if you tried to be a bit clearer you would avoid misunderstanding.

> Everyone seems to assume
> any opponent of C must be some reactionary neanderthal committed to
> Fortran.

Again, if this isn't your intention you're not doing a good job of
making your intentions clear.

> Neither C nor Fortran are advances.  There are things to be learned
> from both of them though - mistakes as well as good ideas.  I can't
> understand the "reactionary neanderthal" attitude of many C programmers
> who seem to feel that there's no way to improve their language and
> no point in discussing its faults.

The point is that C is, like Fortran, pretty much set in concrete. To
make the sort of changes you're arguing for will require a new language.
The main difference between the people on X3J11 and the people on X3J3
is that the former group was aware of that. That's why Ansi C is a reality,
and why Ansi Fortran has been repudiated in favor of the original standard.

We have in the past had discussions in this newsgroup on what a good
successor to C is... a systems programming language for the next century.
That's the sort of thing you should be working on. We're looking towards
automobiles, while you're arguing for a mechanical horse.

I asked three questions. You didn't answer them. I'd let the matter drop but
I really would like the answers...

> > 		DATA I /0/
> > 		J = I * GETCH(5)
> > 		J = 0 * GETCH(6)

> > Is this legal?
> > Is it guaranteed that GETCH(5) will be evaluated?
> > Is it guaranteed that GETCH(6) will be evaluated?

Perhaps you would be so good as to answer them?

> However, C does not guarantee that the following two functions will
> be evaluated:

>       if (getch(5) && getch(6)) {...}

No, but it guarantees when they will and will not be evaluated. Does
Fortran?

> Once again, your assumption that I believe Fortran to be perfect is
> not correct.

If you don't want people to bring up the shortcomings of Fortran,
then stop USING it as some sort of ideal to which C can only aspire.

Damnit.
-- 
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
"That particular mistake will not be repeated.  There are plenty of        'U`
 mistakes left that have not yet been used." -- Andy Tanenbaum (ast@cs.vu.nl)