Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!rutgers!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.c
Subject: Re: ambiguous ?
Message-ID: <14114@lanl.gov>
Date: 25 Oct 89 00:04:29 GMT
References: <6658@ficc.uu.net>
Organization: Los Alamos National Laboratory
Lines: 55

From article <6658@ficc.uu.net>, by peter@ficc.uu.net (Peter da Silva):
> [...]                                      That's why Ansi C is a reality,

The C standard has been through 3 public reviews and is presently facing
a class-action suit.  It is still not an official standard.  This does
not qualify as "a reality" in my book.

> 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 agree that we _should_ be working toward the "a systems programming
language for the next century".  It is for this reason (among others) that
I post articles in opposition to the view widely promoted in this newsgroup
that C as it currently exists is _already_ the language of the future.
C users aren't looking toward automobiles _or_ mechanical horses but are
maintaining that there's no need to advance past their plug of a horse.
In fact, I would argue that the systems programming language for the next
century is not a successor to C at all since I would dispute the claim
that C is _the_ systems programming language of this century.

> [...]
> 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?                                    [YES]
-- > Is it guaranteed that GETCH(5) will be evaluated? [No - as far as I know]
-- > Is it guaranteed that GETCH(6) will be evaluated? ["    "   "  "  "  "  ]

>> 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,

People can bring up shortcomings of Fortran all they want, I won't
be offended.  The only cases that offend me are misrepresentations
of Fortran which serve no one's interest.  Meanwhile, Fortran is still
in a vulnerable period with respect to the next standard - exposing
true shortcomings _may_ be rewarded by some redress of the problem by
the committee (not likely, but not impossible).

> then stop USING it as some sort of ideal to which C can only aspire.

I don't.  If you'll search back, the first mention of Fortran in this 
thread was _not_ mine.  It was submitted by someone that _also_ assumed
that I would be embarrassed by some failing in Fortran.  The above
example is also not mine.  If memory serves, it's yours!  I'm perfectly
willing to use Fortran as a vehicle of comparison, but I don't use it
as an "ideal".

As far as the above example goes, it is a mistake for the rules of Fortran
to behave in the manner implied.  That doesn't excuse C of any of its
failings.  It simply means that Fortran has some of its own.