[comp.lang.c] ambiguous ?

bagpiper@pnet02.gryphon.com (Michael Hunter) (10/16/89)

In the following code fragment is line 3 ambiguous from an X3J11 standpoint
or from a historical standpoint.

1) int Ret ;
2)
3) func(Ret = func2(), Ret+30) ;

I wouldn't normally write code like this, but I ran across code similar to
this in a program I am maintaining, and, as long as it isn't ambigous to some
large subset of the existing compilers, I will probably leave it be.

*Ambiguous is probably not the right word...at least to a specific compiler,
since a specific compile will probably evaluate func's parameters in a
consistent manner.  What I am worried about is if there exists two compilers A
and B such that A evaulates the parameters of func R to L and B evaluates the
parameters of func L to R.

                                        Michael
PS  What is the status of ANSI C?  Has the proposed standard passed the X3
committee?  If so when and where can I get of copy of the standard (and for
how much).  If not, how much longer does it appear that it will take for it to
be passed.

Mike Hunter - Box's and CPU's from HELL: iapx80[012]86, PR1ME 50 Series, 1750a
UUCP: {ames!elroy, <routing site>}!gryphon!pnet02!bagpiper
INET: bagpiper@pnet02.gryphon.com

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/16/89)

In article <20974@gryphon.COM> bagpiper@pnet02.gryphon.com (Michael Hunter) writes:
>In the following code fragment is line 3 ambiguous from an X3J11 standpoint
>or from a historical standpoint.
>3) func(Ret = func2(), Ret+30) ;

Both, because the order in which function arguments are evaluated has
always been implementation-dependent.  In fact I've seen both orders used.
Usually, the order is determined by the "natural" addressing order for the
way that functions push and pop off machine stacks, and both directions of
"natural" stack growth are commonly encountered.

>PS  What is the status of ANSI C?  Has the proposed standard passed the X3
>committee?  If so when and where can I get of copy of the standard (and for
>how much).  If not, how much longer does it appear that it will take for it to
>be passed.

Yes, X3 reaffirmed the technical side of the proposed ANSI standard for C.
All that remains is for Hansberry's procedural appeal to be considered.
From a message received recently from Tom Plum (X3J11 Vice Chair):

	By the way, the X3J11 situation is that a meeting has been scheduled
	for the panel to hear the procedural appeal; it is set for 20 October.
	We certainly expect that X3J11 and X3 will be upheld by the panel,
	but there is not much more I can tell you.  If all goes well, we will
	reach the 15 December meeting of ANSI Board of Standards Review.

The proposed ANSI Standard is still the one described in the December 7, 1988
draft.  I believe it's available from Global Engineering Documents.

bill@twwells.com (T. William Wells) (10/16/89)

In article <20974@gryphon.COM> bagpiper@pnet02.gryphon.com (Michael Hunter) writes:
: In the following code fragment is line 3 ambiguous from an X3J11 standpoint
: or from a historical standpoint.
:
: 1) int Ret ;
: 2)
: 3) func(Ret = func2(), Ret+30) ;

You can't tell which way the arguments will get evaluated. Some
compilers will do them left to right, others right to left. And if it
does them right to left, which I believe is the most common way, you
are in trouble.

X3J11 did not mandate any order of evaluation of function arguments
so this won't be a good idea with ANSI compilers either.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.com

davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/17/89)

In article <20974@gryphon.COM>, bagpiper@pnet02.gryphon.com (Michael Hunter) writes:
|  1) int Ret ;
|  2)
|  3) func(Ret = func2(), Ret+30) ;

  There is no guarantee that args will be evaluated in any given order.
In fact, there are existing compilers today which do it each way, so you
already have a portability problem.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
"The world is filled with fools. They blindly follow their so-called
'reason' in the face of the church and common sense. Any fool can see
that the world is flat!" - anon

grogers@sushi.uucp (Geoffrey Rogers) (10/17/89)

In article <20974@gryphon.COM> bagpiper@pnet02.gryphon.com (Michael Hunter) writes:
>In the following code fragment is line 3 ambiguous from an X3J11 standpoint
>or from a historical standpoint.
>
>1) int Ret ;
>2)
>3) func(Ret = func2(), Ret+30) ;
>
>I wouldn't normally write code like this, but I ran across code similar to
>this in a program I am maintaining, and, as long as it isn't ambigous to some
>large subset of the existing compilers, I will probably leave it be.
>

In both K&R I and pANSI C the evaulation order of parameters being pass 
to a function is undefined. This means that if you compile the above code 
with two different compilers you could get two different answers!

You should rewrite the code as follows:

1) int Ret ;
2)
3) Ret = func2() ;
4) func(Ret, Ret+30) ;

Geoffrey C. Rogers

jlg@lanl.gov (Jim Giles) (10/17/89)

From article <11312@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
> In article <20974@gryphon.COM> bagpiper@pnet02.gryphon.com (Michael Hunter) writes:
>>In the following code fragment is line 3 ambiguous from an X3J11 standpoint
>>or from a historical standpoint.
>>3) func(Ret = func2(), Ret+30) ;
> 
> Both, because the order in which function arguments are evaluated has
> always been implementation-dependent.  [...]
  ^^^^^^

Maybe that's what it has "always" been - but the ANSI standard says
different.  The ANSI standard has three different categories for
'ambiguous' constructs: 1) _Unspecified_ - the standard imposes no
requirements at all; 2) _Undefined_ - The construct is illegal or
non-portable, the standard imposes no requirements; 3) _Implementation_
_defined_ - the behaviour is determined by the implementation.

The order of evaluation of function arguments is _Unspecified_ not
_Implementation_defined_.  This means that the evaluation order is
allowed to vary EVEN WITHIN AN IMPLEMENTATION!  This is supposedly
to allow optimization.

It is my opinion that _Unspecified_ and _Undefined_ have no place in
a language definition.  _Implementation_defined_ should be used as little
as possible.  Apparently, X3J11 thought otherwise (this makes C the only
ANSI language with deliberately undefined, as opposed to implementation
defined, behaviour).

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/17/89)

In article <14089@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>From article <11312@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
>> Both, because the order in which function arguments are evaluated has
>> always been implementation-dependent.  [...]
>Maybe that's what it has "always" been - but the ANSI standard says
>different.

You should not try to explain to others concepts with which you
obviously disagree, because you let your personal bias get in the way.

What I said is absolutely correct, and agrees with the Standard.
Perhaps you don't know what "dependent" means?

The proposed ANSI Standard for C leaves the order of argument
evaluation unspecified, thus it depends on the implementation.
This is indeed the way it always has been.

diamond@csl.sony.co.jp (Norman Diamond) (10/17/89)

In article <14089@lanl.gov> jlg@lanl.gov (Jim Giles) writes:

>(this makes C the only
>ANSI language with deliberately undefined, as opposed to implementation
>defined, behaviour).

Unusual as it is for me to find something defensible about C, this is
one.  LOTS of languages have deliberately undefined behavior.  In fact,
regarding the matter under discussion (evaluation order of actual
parameters to a function call), I'd conjecture that EVERY traditional
language leaves it undefined.  (I suppose something like FORTH might
define it by accident because of general rules of the language.)

-- 
Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work)
  Should the preceding opinions be caught or     |  James Bond asked his
  killed, the sender will disavow all knowledge  |  ATT rep for a source
  of their activities or whereabouts.            |  licence to "kill".

henry@utzoo.uucp (Henry Spencer) (10/18/89)

In article <14089@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>... 1) _Unspecified_ - the standard imposes no
>requirements at all; 2) _Undefined_ - The construct is illegal or
>non-portable, the standard imposes no requirements; 3) _Implementation_
>_defined_ - the behaviour is determined by the implementation.

A more accurate definition of _implementation_ _defined_ is that the
behavior is determined by the implementation *and must be documented*.
Otherwise it doesn't differ from _unspecified_ in any useful way.

>The order of evaluation of function arguments is _Unspecified_ not
>_Implementation_defined_.  This means that the evaluation order is
>allowed to vary EVEN WITHIN AN IMPLEMENTATION!  This is supposedly
>to allow optimization.

Yup.  Which it does.  (For example, in an argument list with expressions
of varying complexity, on a machine with few registers that wants to pass
arguments in registers, it is best to evaluate the complicated arguments
first so that the maximum number of registers are available for the job.)
This is the same, for much the same reasons, as letting subexpressions
of a single expression be evaluated in arbitrary order.  What's wrong
with it?

>... (this makes C the only
>ANSI language with deliberately undefined, as opposed to implementation
>defined, behaviour).

I could have sworn that a good many things were officially undefined in
Fortran (66 or 77, take your pick), such as the values of local variables
after return from a function.  I could be wrong -- I'm not a Fortran guru.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

jlg@lanl.gov (Jim Giles) (10/18/89)

From article <11318@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
> The proposed ANSI Standard for C leaves the order of argument
> evaluation unspecified, thus it depends on the implementation.
> This is indeed the way it always has been.

If they had meant that the behaviour was simply implementation defined,
that's what they would have said.  The standard SPECIFICALLY separates
the concept of implementation defined from the concept of unspecified
behaviours.

jlg@lanl.gov (Jim Giles) (10/19/89)

From article <1989Oct17.203733.23121@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer):
> I could have sworn that a good many things were officially undefined in
> Fortran (66 or 77, take your pick), such as the values of local variables
> after return from a function.  I could be wrong -- I'm not a Fortran guru.

That's a different definition of _undefined_ and you know it.  The Fortran
use is a description of the status of those variables.  In C, the _behaviour_
of the program is what's undefined.  The closest thing in Fortran is the
explicit optimization allowed in expressions (ie. the expression can be
reordered in by _mathematically_ valid identities).  However, Fortran
provides an _efficient_ way to override such optimization.  C has _many_
more contexts which are _both_ undefined and without efficient ways
of overriding the ambiguity.

This is not to say that Fortran is perfect - it isn't.  But it is a better
defined and more clearly specified language.  I know several people who
don't use C simply because its behaviour is deliberately undefined and
there is no clear way of explicitly overriding such ambiguities.

henry@utzoo.uucp (Henry Spencer) (10/19/89)

In article <14091@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>> I could have sworn that a good many things were officially undefined in
>> Fortran (66 or 77, take your pick), such as the values of local variables
>> after return from a function.  I could be wrong...
>
>That's a different definition of _undefined_ and you know it.  The Fortran
>use is a description of the status of those variables.  In C, the _behaviour_
>of the program is what's undefined...

On machines where some values will cause traps when used, I think the
difference is real hair-splitting.  My recollection, admittedly a bit
dim, is that in ANSI Fortran it is flatly illegal to reference a
variable with an undefined value.  I don't see the big difference.

>... C has _many_
>more contexts which are _both_ undefined and without efficient ways
>of overriding the ambiguity.

Sure there are efficient ways:  avoid depending on the ambiguity.  Oddly
enough, this seldom bothers experienced C programmers.  Nobody ever claimed
C was suitable for beginners.

>... I know several people who
>don't use C simply because its behaviour is deliberately undefined and
>there is no clear way of explicitly overriding such ambiguities.

Rational arguments are useless against superstition.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/19/89)

In article <14090@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
-From article <11318@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
-> The proposed ANSI Standard for C leaves the order of argument
-> evaluation unspecified, thus it depends on the implementation.
-> This is indeed the way it always has been.
-
-If they had meant that the behaviour was simply implementation defined,
-that's what they would have said.

If *I* had meant that the behavior was implementation defined, that's
what *I* would have said!  Can't you read, or what?

-The standard SPECIFICALLY separates the concept of implementation
-defined from the concept of unspecified behaviours.

You look mighty foolish trying to "explain" this to me.

	- D A Gwyn
	  X3J11 Response Document Editor

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/19/89)

In article <14091@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>This is not to say that Fortran is perfect - it isn't.  But it is a better
>defined and more clearly specified language.  I know several people who
>don't use C simply because its behaviour is deliberately undefined and
>there is no clear way of explicitly overriding such ambiguities.

To be more precise, that may be their reasoning.
It doesn't mean it's correct.
Many other programmers have turned to C as being
much more useful for developing portable code.

The looseness in the C language definition is deliberate,
because C was designed for systems programming,
where it is important for the compiler to produce simple,
fast code without undue constraints.
Nevertheless, there are sufficient rules that programs
that follow the rules will be highly portable.

exspes@gdr.bath.ac.uk (P E Smee) (10/19/89)

In article <1989Oct17.203733.23121@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>A more accurate definition of _implementation_ _defined_ is that the
>behavior is determined by the implementation *and must be documented*.
>Otherwise it doesn't differ from _unspecified_ in any useful way.
>
How about, as a pragmatic distinction, the idea that if your program
relies on some effect of Implementation Defined behavior, it is correct
but non-portable; while if it relies on some effect of Unspecified
behavior, it is an incorrect program. ?
-- 
 Paul Smee               |    JANET: Smee@uk.ac.bristol
 Computer Centre         |   BITNET: Smee%uk.ac.bristol@ukacrl.bitnet
 University of Bristol   | Internet: Smee%uk.ac.bristol@nsfnet-relay.ac.uk
 (Phone: +44 272 303132) |     UUCP: ...!mcvax!ukc!gdr.bath.ac.uk!exspes

peter@ficc.uu.net (Peter da Silva) (10/19/89)

OK, what is the order of argument evaluation in Fortran?

That is, if I do:

	INTEGER FUNCTION RAND(NEWSEED)
	INTEGER SEED
	INTEGER NEWSEED

	IF ( NEWSEED .EQ. 0 ) THEN
	   ... code to generate new random number ...
	   SEED  = ... whatever ...
	ELSE
	   SEED = NEWSEED
	ENDIF

	RAND = SEED

	END

And then:

	I = RAND(very carefully designed seed)
	CALL HOOPY(RAND(0), RAND(0), RAND(0))

Will this program produce the same output on different machines? Is this
guaranteed?
-- 
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
"You can tell when a USENET discussion is getting old when one of the      'U`
 participants drags out Hitler and the Nazis" -- Richard Sexton

jlg@lanl.gov (Jim Giles) (10/20/89)

From article <1989Oct19.022327.6730@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer):
> [...]                             My recollection, admittedly a bit
> dim, is that in ANSI Fortran it is flatly illegal to reference a
> variable with an undefined value.  I don't see the big difference.

If you don't see the difference between something that is illegal
an something which is legal but has no meaning, you just aren't looking.
Besides, C also has the problem of undefined variables and doesn't
detect them for the same reasons.  It's legal but undefined behaviour
that I'm complaining about.

>>... C has _many_
>>more contexts which are _both_ undefined and without efficient ways
>>of overriding the ambiguity.
> 
> Sure there are efficient ways:  avoid depending on the ambiguity.  Oddly

I _don't_ depend on ambiguity.  I _don't_ use language features which
admit of ambiguous behaviour.  Unfortunately, there is no way of using
C efficiently without also using ambiguous features.  (For example, in
the current discussion, the only way to get a reliable evaluation order
for the function arguments is to do redundant assignments in previous
statements.  Most C compilers are _VERY_ bad a optimizing such sequences.)

> enough, this seldom bothers experienced C programmers.  Nobody ever claimed
> C was suitable for beginners.

I am a reasonably experienced C programmer.  I wrote a compiler for my
home system ten years ago just to learn the language.  Yet I am _always_
bothered by the ambiguous features of the language.  I am bothered that
there is no efficient way around them.  You can't even force the evaluation
order of an expression in C.

> Rational arguments are useless against superstition.

Presisely so.  That is why it's so hard to convince C fanatics that
there may be something wrong with their god (the C programming language
that is).

The primary purpose of a programming language is to _unambiguously_
specify the operation of an algorithm.  The extent to which C violates
this is the extent to which C fails in the _purpose_ of a programming
language.  This is a perfectly rational argument.  I suspect you will
ignore it.

jlg@lanl.gov (Jim Giles) (10/20/89)

From article <11330@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
> In article <14090@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
> -The standard SPECIFICALLY separates the concept of implementation
> -defined from the concept of unspecified behaviours.
> 
> You look mighty foolish trying to "explain" this to me.
> 
> 	- D A Gwyn
> 	  X3J11 Response Document Editor

I am _not_ trying to "explain" this.  I don't agree with it, so I don't
have an explanation of it at all.  I am simply stating a fact which
can be determined by direct reference to the proposed standard itself.
The standard specifically contains the two concepts _separately_.
The meaning of this separation is clear - the implementation is _not_
required to specify a particular interpretation of "unspecified"
features.  That is, the interpretation of such features is not
required to be consistant _within_ an given implementation - much
less between different implementations.

That is the only way to interpret the way the proposed standard is
worded.  As for an _explanation_, I offer none.  You are correct
if you are implying that an explanation is due.  You _may_ even
be the proper one to provide such an explanation.

Frankly, I think the standard committee looks mightly foolish
having defined the standard in this way....

bill@twwells.com (T. William Wells) (10/20/89)

In article <14090@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
: From article <11318@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
: > The proposed ANSI Standard for C leaves the order of argument
: > evaluation unspecified, thus it depends on the implementation.
: > This is indeed the way it always has been.
:
: If they had meant that the behaviour was simply implementation defined,
: that's what they would have said.  The standard SPECIFICALLY separates
: the concept of implementation defined from the concept of unspecified
: behaviours.

Perhaps this silly argument will go away when the participants
realize that they are arguing over the difference between
implementation *dependent* and implementation-*defined*? The
former is descriptive and has no special meaning; the latter is a
special term defined in the standard.

Check back and I think you'll see that Doug did not say that this
was implementation-*defined*.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.com

jlg@lanl.gov (Jim Giles) (10/20/89)

From article <11337@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
> [...]
> The looseness in the C language definition is deliberate,
> because C was designed for systems programming,

It seems to me that systems programming is exactly the context
where "looseness" is least tolerable.  A system failure may
effect hundreds (even thousands) of users.  The cost in user
time as well as information may be enormous.  Systems programming
is the one context in which I would insist upon the _most_
unambiguously designed language available.

jeenglis@nunki.usc.edu (Joe English) (10/20/89)

jlg@lanl.gov (Jim Giles) writes:

>The primary purpose of a programming language is to _unambiguously_
>specify the operation of an algorithm.  The extent to which C violates
>this is the extent to which C fails in the _purpose_ of a programming
>language.  This is a perfectly rational argument.  I suspect you will
>ignore it.

That's not a perfectly rational argument:
You *can* unambiguously specify the operation
of any algorithm in C.  The existence of 
legal expressions that are ambiguous doesn't
take away from the unambiguous ones.

The reason why C is one of the few languages
that accepts ambiguous statements is because C is
one of the few languages that allows more than
one side effect inside an expression.  I think
that's a more than reasonable tradeoff as long as
you know what you're doing.  The utility of
constructs like increment operators, treating
assignment like any other expression, and so on,
are well established.  So they lead to ambiguities
*if improperly used*.  So what?

[ Out of context quote follows: ]

> [...]it's so hard to convince C fanatics that
>there may be something wrong with their god (the C programming language
>that is).

All Hail the Mighty C, and its Prophets K&R!

[ Sorry, I couldn't resist that one... ]

--Joe English

  jeenglis@nunki.usc.edu.  

ok@cs.mu.oz.au (Richard O'Keefe) (10/20/89)

In article <6591@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes:
> 	INTEGER FUNCTION RAND(NEWSEED)
> 	INTEGER SEED
> 	INTEGER NEWSEED

The code sketch which follows relies on the value of SEED being preserved
between calls.  However, a Fortran compiler is allowed to implement local
variables _either_ as "static" _or_ as "auto", at whim.  If you need the
equivalent of C "static" variables, you have to say

	SAVE SEED

(Strictly speaking this may also be needed for COMMON blocks, but it is
most unlikely to give you trouble on a system without overlays.)

> 	CALL HOOPY(RAND(0), RAND(0), RAND(0))

A Fortran compiler is explicitly permitted to compile this as if you
had written
	ITEMP = RAND(0)
	CALL HOOPY((ITEMP), (ITEMP), (ITEMP))

> Will this program produce the same output on different machines?
No.

> Is this guaranteed?

An even simpler example:
	ITEMP = 0*RAND(0)
Whether this calls RAND or not is up to the compiler.

blarson@basil.usc.edu (bob larson) (10/20/89)

In article <14093@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>From article <11330@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
>> -The standard SPECIFICALLY separates the concept of implementation
>> -defined from the concept of unspecified behaviours.
>The standard specifically contains the two concepts _separately_.
>Frankly, I think the standard committee looks mightly foolish
>having defined the standard in this way....

Perhaps an analogy would help.

A 100 mile race course has a small section of track with snow on it,
and a paved (but longer) detour around this section.  There is a
desire to standardize racecar design between various tracks, and since
most courses have no snowy section, the detour is made the "official"
racecourse.  (Existing cars are faster there anyway, and less likely
to get in accidents.) One racecar driver insists that the snowy
section be made the official route, and that all racecars be equipted
with tire chains.  The factual arguments that it is faster on both
normal racecourses and the one with the snowy section not to have tire
chains have no effect on this driver, he continually drives over the
snowy section and crashing regularly.  Are we supposed to have
sympathy for this driver?  For some unknown reason, he isn't choosing
to drive an existing 4-wheel drive car.

--  
Bob Larson	blarson@basil.usc.edu		usc!basil!blarson
--**		To join Prime computer mailing list		**---
info-prime-request@ais1.usc.edu		usc!ais1!info-prime-request

amull@Morgan.COM (Andrew P. Mullhaupt) (10/20/89)

In article <11337@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
> 
> The looseness in the C language definition is deliberate,
> because C was designed for systems programming,
> where it is important for the compiler to produce simple,
> fast code without undue constraints.
> Nevertheless, there are sufficient rules that programs
> that follow the rules will be highly portable.

Doug, you seem to have the most level-headed approach to C and its
forthcoming standard. I don't like much about C, but I don't want
to just bash it here. I want to ask you:

    OK, so how can I avoid following commonly available bad rules or
mispractices in C programming? I have for years programmed in Pascal
(and several other languages - none of 'em perfect, either...) but
C poses a steeper learning curve than any other. (I am now employed
to program extensively in APL2, which comes in second.) I am not
satisfied with writing merely functional programs; I want them to 
be clear and clean and run everywhere. I want them to be easy to
maintain and upgrade. Where can I turn to get the kind of advice
Doug Cooper hands out in his book "Standard Pascal"? I have found
Harbison and Steele to be the best so far, but other, highly expert
C programmers I know cringe at the idea of learning to program C from
"That Lisp Guy". Should I worry about this?

   Also: is there a logical exegesis of a fairly full subset of C? 
For example, a set of proof rules in the literature somewhere? I
have for years been complaining about the difficulty of unbound
pointers in this regard, but I am perhaps out of date. (Did the 
ANSI standardization affect this problem? I'm pretty sure it
didn't, but I cannot give an authoritative reference.) There
have been graduate courses for years where every jot and tittle
of PL/I or Algol 68 are thrashed out in agonizing detail. Anyone
ever done this for C? 

    I'm not suggesting that PL/I or Algol 68 are better languages;
(attempt to cut down on flamage here), I just want to know where can
I get the straight dope on C short of the standard itself, (if
possible).

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/20/89)

In article <1989Oct19.225004.20120@twwells.com> bill@twwells.com (T. William Wells) writes:
-Perhaps this silly argument will go away when the participants
-realize that they are arguing over the difference between
-implementation *dependent* and implementation-*defined*? The
-former is descriptive and has no special meaning; the latter is a
-special term defined in the standard.

I've known that all along -- I was waiting for Giles to discover it.
However, given his reason postings it's not clear he even lives in
the same universe as the rest of us.

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/20/89)

In article <20685@usc.edu> blarson@basil.usc.edu (bob larson) writes:
>>From article <11330@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
[followed by two quotations, NEITHER of them anything I had said.]

PLEASE edit your attributions more carefully..

>Perhaps an analogy would help.

Then again, perhaps not.
I sure didn't think it helped clarify what we were talking about.

peter@ficc.uu.net (Peter da Silva) (10/21/89)

In article <14092@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
> the current discussion, the only way to get a reliable evaluation order
> for the function arguments is to do redundant assignments in previous
> statements.  Most C compilers are _VERY_ bad a optimizing such sequences.)

Yes, this is true. However, the only time this matters is when your function
arguments have a side effect; when this occurs in more than one argument; and
when the side effect interact. This allows the compiler to optimise for the
common case at the expense of a rare case.

> I am a reasonably experienced C programmer.

You are an experienced Fortran programmer who has learned to speak C
fluently. You don't think in it, as is demonstrated by your frequent
postings flaming about this or that aspect of C that offends you.

I think it's time for comp.lang.jim-giles-and-herman-rubin.
-- 
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
"You can tell when a USENET discussion is getting old when one of the      'U`
 participants drags out Hitler and the Nazis" -- Richard Sexton

peter@ficc.uu.net (Peter da Silva) (10/21/89)

In article <14094@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
> Systems programming
> is the one context in which I would insist upon the _most_
> unambiguously designed language available.

If you could force designers to produce a standard hardware architecture
that is unambiguously designed then this would be a worthwhile goal.

Sometimes even C is to large, clumsy, and/or overspecified for some set
of problems. Like, very small embedded controllers.

What does "ERROR=label" mean in an embedded application?
-- 
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
"You can tell when a USENET discussion is getting old when one of the      'U`
 participants drags out Hitler and the Nazis" -- Richard Sexton

peter@ficc.uu.net (Peter da Silva) (10/21/89)

[ in Fortran,

	CALL SUBR(FUNC, FUNC)

May be called as

	TEMP=FUNC
	CALL SUBR(TEMP, TEMP)

Which is an even greater liberty with the calling sequence than C is
permitted ]

Thank you.

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.
-- 
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
"You can tell when a USENET discussion is getting old when one of the      'U`
 participants drags out Hitler and the Nazis" -- Richard Sexton

henry@utzoo.uucp (Henry Spencer) (10/21/89)

In article <14092@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>... Unfortunately, there is no way of using
>C efficiently without also using ambiguous features.  (For example, in
>the current discussion, the only way to get a reliable evaluation order
>for the function arguments is to do redundant assignments in previous
>statements.  Most C compilers are _VERY_ bad a optimizing such sequences.)

Gee, I guess I've been using C inefficiently all these years, including in
various bits of work on performance improvement.  Funny that I never realized
it.  Personally, my view is that code which relies on order of evaluation
within expressions -- except in a few well-defined cases like C's && and
|| operators -- is broken even if the language specifies a precise meaning.

>The primary purpose of a programming language is to _unambiguously_
>specify the operation of an algorithm...

If you want specifications, try denotational semantics.  The purpose of
a programming language is to make the algorithm executable.  This always
involves compromises.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

henry@utzoo.uucp (Henry Spencer) (10/21/89)

In article <14094@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>> The looseness in the C language definition is deliberate,
>> because C was designed for systems programming,
>
>It seems to me that systems programming is exactly the context
>where "looseness" is least tolerable...

Unmanaged and unexpected looseness is indeed intolerable.  Looseness that
the programmer is aware of and allows for may make the difference between
a program which is too slow to do the job and one that runs efficiently.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

jlg@lanl.gov (Jim Giles) (10/21/89)

From article <6591@ficc.uu.net>, by peter@ficc.uu.net (Peter da Silva):
> [... RAND defined with the usual side effects ...] 
> And then:
> 
> 	I = RAND(very carefully designed seed)
> 	CALL HOOPY(RAND(0), RAND(0), RAND(0))
> 
> Will this program produce the same output on different machines? Is this
> guaranteed?

The call to HOOPY is not standard conforming.  The relevant part of the
standard is:

      6.6.2 [...]
      In a statement that contains more than one function
      reference, the value provided by each function reference
      must be independent of the order chosen by the processor for
      evaluation of the function references.

As I have said before, Fortran isn't perfect.  In this case it is
overly restrictive in the same way that C under-restrictive.  I would
prefer to be able to explicitly declare whether a function has side-effects
and the allow the processor to optimize all calls to side-effect free
functions.  For functions _with_ side-effects, the 'left-to-right'
rule could apply with no particular hardship.

This is different than the issue under discussion with C though.
Here, the arguments may have side-effects _without_ even calling
a function.  In this case, any compiler smart enough to usefully
optimize the argument preparation is alse smart enough to detect
the dependencies among arguments and enforce an order among them.
I see no reason that the language standard couldn't require this
to be done.

jlg@lanl.gov (Jim Giles) (10/21/89)

From article <5863@merlin.usc.edu>, by jeenglis@nunki.usc.edu (Joe English):
> [...]                      The utility of
> constructs like increment operators, treating
> assignment like any other expression, and so on,
> are well established.  [...]

Really?  The only ergonomical experiments I've seen on this issue
indicate that such side-effects within expressions are _detrimental_
to programmer productivity.  such experiments were done of languages
as different as APL and TOPPS.  Productivity always was _better_
for variants of the language with expression side-effects removed.

jlg@lanl.gov (Jim Giles) (10/21/89)

From article <11362@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
> In article <20685@usc.edu> blarson@basil.usc.edu (bob larson) writes:
>>Perhaps an analogy would help.
> 
> Then again, perhaps not.
> I sure didn't think it helped clarify what we were talking about.

We agree on something!  I didn't think tha analogy helped either.

jlg@lanl.gov (Jim Giles) (10/21/89)

From article <1989Oct20.175352.20598@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer):
> [...]Personally, my view is that code which relies on order of evaluation
> within expressions -- except in a few well-defined cases like C's && and
> || operators -- is broken even if the language specifies a precise meaning.

Gee, isn't it interesting that the only order dependent behaviour you
are willing to trust are the "well-defined" && and || operators.  Those
also happen to be the only ones (besides commas - which you presumably
also allow) that enforce order.  This is another one of those "Anything
C does is right, everything else is not" arguments.  Presumably, if C
made argument evaluation in function calls "well-defined", you would
would have no qualms depending on their order either.  Since that has
been the point I've tried to make all along - I rest my case.

> [...]                                                    The purpose of
> a programming language is to make the algorithm executable.  This always
> involves compromises.

If it involves compromises of correctness, the language is not worth
pursuing.  If it involves _unnecesasary_ compromises of efficiency,
the language is in need of modification.  C requires one or the other
compromise.

henry@utzoo.uucp (Henry Spencer) (10/21/89)

In article <14098@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>...  such experiments were done of languages
>as different as APL and TOPPS.  Productivity always was _better_
>for variants of the language with expression side-effects removed.

I'm not familiar with the APL experiments... but as far as TOPPS, one
should bear in mind that TOPPS1 was an awful language (I speak as
someone who programmed in it) and TOPPS2 made a whole bunch of, on
the whole, badly needed changes.  Concluding that TOPPS2 was superior
to TOPPS1 because of the side-effect issue alone is laughable.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

henry@utzoo.uucp (Henry Spencer) (10/21/89)

In article <14102@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>> [...]Personally, my view is that code which relies on order of evaluation
>> within expressions -- except in a few well-defined cases like C's && and
>> || operators -- is broken even if the language specifies a precise meaning.
>
>Gee, isn't it interesting that the only order dependent behaviour you
>are willing to trust are the "well-defined" && and || operators...

Not really.  All it means is that I think C got this particular decision
right.

>...  Presumably, if C
>made argument evaluation in function calls "well-defined", you would
>would have no qualms depending on their order either...

Your presumption is incorrect.  The whole purpose of && and || is to force
conditional evaluation, and hence evaluation order.  I have no objection
to operators whose specific purpose is to force order, when they are
broadly useful.  I do have considerable objection to code that depends
on evaluation order *without* putting the reader on notice of it by
explicitly using forcing operators.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

henry@utzoo.uucp (Henry Spencer) (10/21/89)

In article <14102@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>If it involves compromises of correctness, the language is not worth
>pursuing...

How can you possibly bear to use floating-point arithmetic, then?  No
floating-point representation on any actual machine correctly implements
the real numbers (despite misuse of the word "REAL" in Fortran).  Instead
they implement horribly messy approximations, placing great demands on
the programmer or numerical analyst to demonstrate that his results can
actually be trusted.  The reasoning required for this is orders of
magnitude more complex than anything needed to deal with C's compromises.
Most Fortran programmers, of course, either don't bother at all or use
what Ric Hehner has dubbed "engineering induction":  "if it works for
n = 1, 2, and 3, that's good enough for me".  This is a rather unfortunate
attitude, considering how increasingly dependent we are on correct results
from engineering software.

Avoiding this nasty compromise requires doing all math symbolically, using
complex and difficult exact representations, or at the very least using
a very carefully-designed interval-arithmetic package.  How one does any
of these things in Fortran is beyond me.  Jim, perhaps you could elaborate
on how you've solved this one?  (I assume you have, since you get so upset
about C's problems, which are trifling by comparison.)
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

tarvaine@tukki.jyu.fi (Tapani Tarvainen) (10/21/89)

In article <6611@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:

>>  a reliable evaluation order
...
> the only time this matters is when your function
>arguments have a side effect; when this occurs in more than one argument; and
>when the side effect interact.

Another situation where order of evaluation matters (and in my -
admittedly limited - experience, a more common one, as well as harder
to circumvent when it really matters) is when intermediate overflows
or rounding errors are possible, especially with floating point
numbers.  (Ever tried to implement extended precision floating point
arithmetic with Dekker formulas or some such?)
-- 
Tapani Tarvainen    (tarvaine@tukki.jyu.fi, tarvainen@finjyu.bitnet)

amull@Morgan.COM (Andrew P. Mullhaupt) (10/22/89)

In article <6611@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes:
> In article <14092@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
> > I am a reasonably experienced C programmer.
> 
> You are an experienced Fortran programmer who has learned to speak C
> fluently. You don't think in it, as is demonstrated by your frequent
> postings flaming about this or that aspect of C that offends you.
> 
> I think it's time for comp.lang.jim-giles-and-herman-rubin.
Count me in (sort of). Sure, I too come to C from another programming
language. In fact I come from about four or five. Let's get one thing
straight - They tell you when you learn APL that you will learn to 
think in it; They tell you when you learn OO style language that you
need to think a new way. You want to put C on this list? FINE. But
let's draw the line between programming as a professional activity
and writing programs as a traditional ritualized observation. I 
quote from one of my favorite axioms of programming:

From David Gries, "The Science of Computer Programming", (1981)
Springer-Verlag, New York.

page 235.: "*PRINCIPLE: Program INTO a programming language, not
                        IN it."

As I continue to study C, I find that the Draft Standard is a resonable
attempt to lay out a language capable of expressive, readable
representations of algorithms without destroying the connection to
the less well defined past. This is not a swipe at the original
K&R, either; but at the wide variety of existing implementations
which seem to make a mockery of the word standard. 

Perhaps there are a lot of C programmers who do not feel inclined to
poke through all the nooks and crannies of the Standard, or of their
own local flavor of C, but it is a short term view in my opinion. The
pain of this round of standardization is a result of the long delay
since the last. Ada has surely suffered from the length of its ten
year standardization cycle; Pascal is surely in need of an overhaul;
Isn't it obvious that as our understanding of algorithms evolves,
and so does our hardware, that our language technology needs to grow
but in a controlled way? You don't want to commit to a language that
is totally different next year, nor one which will not meet your needs.
But this is no argument against a strong standard, and a consistent
one.

Don't tell me to think in C. Don't tell me to think in any computer
language. I have devoted a large portion of my life to learning how
to think, (with mixed success, perhaps), but I know enough to trust
David Gries' admonition. 

PROGRAM INTO A LANGUAGE, NOT IN IT!

Later,
Andrew Mullhaupt

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/22/89)

In article <14102@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>If it involves compromises of correctness, the language is not worth
>pursuing.  If it involves _unnecesasary_ compromises of efficiency,
>the language is in need of modification.  C requires one or the other
>compromise.

Hey, Giles, you've already made the point that you don't like C --
many times over!  You're not serving any useful purpose by intruding
your complaints about it into this newsgroup.  Everyone you're arguing
with KNOWS FULL WELL the characteristics of C that you object to.  We
disagree that it makes the language unusable.  We would probably all
agree that these characteristics can make C dangerous in unskilled
hands, too.  C is like a power tool in that regard.

In fact, C offers better support for correct, efficient, portable
programming, particularly of intricate applications, than any other
common programming language, including your beloved Fortran.  Many
commercial software programmers have also come to this conclusion.
You should of course draw your own conclusions, even if they're
based on faulty evidence or reasoning, but there is no need to rant
about C in this newgroup.  Do that in some comparative programming
languages newsgroup instead.

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/22/89)

In article <1989Oct21.072905.9039@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>Most Fortran programmers, of course, either don't bother at all [to prove
>their use of hardware floating-point is correct] ...
>Avoiding this nasty compromise requires doing all math symbolically, using
>complex and difficult exact representations, or at the very least using
>a very carefully-designed interval-arithmetic package.  How one does any
>of these things in Fortran is beyond me.

To be fair, while I agree that most Fortran programmers don't do this
properly, the main emphasis of Fortran is numerical programming, and
there has been a lot of work put into resolving these problems.  The
whole issue is a major branch of the field of numerical analysis.
Some popular Fortran libraries are carefully designed in this regard.

You're right about hardware floating point concerns making C's usual
areas of "ambiguity" (really not the right term for it) appear piddling
by comparison.

mcdonald@uxe.cso.uiuc.edu (10/22/89)

>> 
>> 	I = RAND(very carefully designed seed)
>> 	CALL HOOPY(RAND(0), RAND(0), RAND(0))
>> 
>> Will this program produce the same output on different machines? Is this
>> guaranteed?

>The call to HOOPY is not standard conforming.  The relevant part of the
>standard is:

>      6.6.2 [...]
 >     In a statement that contains more than one function
 >     reference, the value provided by each function reference
 >     must be independent of the order chosen by the processor for
 >     evaluation of the function references.

That last paragraph doesn't seem to apply - if RAND(0) produces
truly random numbers (my best one really does - absolutely, truly
random, as best as I can tell. It digitizes noise.), then
the requirement in the standard is met.  Since the value of each function
reference is independent of everything, it is independent of the
order of calling it! Of course, if you use a FAKE rundom number 
generator - well, that is an interesting question. IF it is a really
good one, the program should still give "correct" answers. 
Of course if you don't REALLY want randomness, then the fragemnt is
clearly non-conforming.

Doug McDonald

henry@utzoo.uucp (Henry Spencer) (10/22/89)

In article <11371@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>>Most Fortran programmers, of course, either don't bother at all [to prove
>>their use of hardware floating-point is correct] ...
>>Avoiding this nasty compromise requires doing all math symbolically, using
>>complex and difficult exact representations, or at the very least using
>>a very carefully-designed interval-arithmetic package.  How one does any
>>of these things in Fortran is beyond me.
>
>To be fair, while I agree that most Fortran programmers don't do this
>properly, the main emphasis of Fortran is numerical programming, and
>there has been a lot of work put into resolving these problems.  The
>whole issue is a major branch of the field of numerical analysis.
>Some popular Fortran libraries are carefully designed in this regard.

I think you've very slightly missed my point, Doug.  What you're saying
is that great efforts have gone into engineering to *cope* with this
compromise, and make it a bit more manageable.  I agree.  But this sort
of thing -- coping intelligently with a compromise that cannot be avoided
in a cost-effective way -- is precisely what Jim was unwilling to accept.
If you insist on *eliminating* the non-ideal behavior, then the numerical
analysis work is irrelevant and more drastic measures are needed.  Then
Fortran falls down badly:  what you need is something like C++, where the
implementation of the arithmetic can be changed.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

peter@ficc.uu.net (Peter da Silva) (10/22/89)

In article <14102@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
> Gee, isn't it interesting that the only order dependent behaviour you
> are willing to trust are the "well-defined" && and || operators.

Short-circuit evaluation of logical operators is a well-researched subject.
In any language in which this can occur (such as C and ADA), the order of
evaluation is well-defined. These particular semantics are *not*, as you
imply, a quirk of the C language.
-- 
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
"ERROR:  trust not in UUCP routing tables"                                 'U`
	-- MAILER-DAEMON@mcsun.EU.net

bill@twwells.com (T. William Wells) (10/23/89)

Followups have been directed to alt.flame.

In article <14092@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
: >>... C has _many_
: >>more contexts which are _both_ undefined and without efficient ways
: >>of overriding the ambiguity.
: >
: > Sure there are efficient ways:  avoid depending on the ambiguity.
:
: I _don't_ depend on ambiguity.  I _don't_ use language features which
: admit of ambiguous behaviour.  Unfortunately, there is no way of using
: C efficiently without also using ambiguous features.

I've been programming mostly in C for seven years now, after
programming in more than a dozen other languages, including
assembly, for another eight, writing software that had to be as
near as absolutely portable as possible (it ran on well over a
hundred different systems), with customers that *did* bitch every
time I screwed up.

Efficiency was a great concern, because end users, you know, the
ones that are the ultimate justification for this business, had
to wait for my programs to finish. And a slow product meant no
sales. I'm known for usually arguing the efficiency side of
programming because I *hate* fat programs. Because of that, I've
developed an arsenal of techniques for writing efficient code;
when I work on improving other people's code I tend to, without
doing nonportable things, improve the code speed by at least 25%.

When it comes to writing portable and efficient code, I generally
know what I am doing.

You, Mr. Giles, just don't know what you are talking about. You
have it on the brain that unspecified behavior causes problems.
And you are magnifying the problem all out of proportion. You are
also ignoring, either out of incompetence or because you just
don't want to hear it, methods of avoiding the problems.

:                                                       (For example, in
: the current discussion, the only way to get a reliable evaluation order
: for the function arguments is to do redundant assignments in previous
: statements.  Most C compilers are _VERY_ bad a optimizing such sequences.)

This is a perfect example of your fixation. First: good
programming practice says that one should avoid multiple side
effects in a statement. There are obvious exceptions, don't waste
my time telling me about them.

Second, your attention to efficiency in that context is
misplaced. Consider the code generated: one function call with
two arguments and their associated computations, as compared with
the same plus one extra store instruction. And, of course, if you
care THAT much about efficiency, you are a damn fool for trying
to get it in a higher level language anyway. TANSTAAFL, folks.

But if you *must* do that, and you don't like the cost of the
redundant assignments, you use the COMMA operator.

You see, if you knew beans about C optimizers, you'd know that
all but the worst don't do too badly with *intra-statement*
optimization. So, if "a=b++; foo(a,b);" bugs you, turn it into
"a=b++, foo(a,b);" and you will likely get better code than you
would have otherwise. (Not, mind you, that I'd ever; there are
plenty of very good reasons for not, and plenty of other, good,
ways to squeeze efficiency out of C programs.)

There are workarounds for each kind of undefined behavior, AND
NONE OF THEM ARE ESPECIALLY EXPENSIVE, your claims to the
contrary.

: > enough, this seldom bothers experienced C programmers.  Nobody ever claimed
: > C was suitable for beginners.
:
: I am a reasonably experienced C programmer.

No, Mr. Giles, you are a person who has programmed in C for years.
You may have knowledge, but you are lacking in C wisdom.

:                                                        Yet I am _always_
: bothered by the ambiguous features of the language.

Solely because you have not bothered to learn efficient ways to
avoid them. You've wasted your time bitching about them.

: bothered by the ambiguous features of the language.  I am bothered that
: there is no efficient way around them.  You can't even force the evaluation
: order of an expression in C.

Use the comma operator. If it really matters. Which it rarely
does.

: > Rational arguments are useless against superstition.
:
: Presisely so.  That is why it's so hard to convince C fanatics that
: there may be something wrong with their god (the C programming language
: that is).

I'm no damn C fanatic. But you are an anti-C fanatic. The mark?
That you complain about something that *makes no difference* in
the real world.

: The primary purpose of a programming language is to _unambiguously_
: specify the operation of an algorithm.

Bull. The primary purpose of programming languages is to get the
job done. Which leads to a secondary purpose: unambiguous
specification of the algorithm. But that is not, past a certain
level of functionality, an imposition on the *language*, it is an
imposition on the *programmer*.

It is clear that you don't care to exercise the responsibility to
be a good programmer. You just want to complain about something
you don't like.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.com

jlg@lanl.gov (Jim Giles) (10/23/89)

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.

jlg@lanl.gov (Jim Giles) (10/23/89)

From article <1989Oct21.070728.8750@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer):
> [...]  bear in mind that TOPPS1 was an awful language (I speak as
> someone who programmed in it) and TOPPS2 made a whole bunch of, on
> the whole, badly needed changes.  Concluding that TOPPS2 was superior
> to TOPPS1 because of the side-effect issue alone is laughable.

Had I made such a conclusion, it would indeed have been laughable.
However, the paper I reference made a detailed study of TOPPS vs.
TOPPS2.  _AMONG_ their conclusions were that assignment should be
more than "just an operator".  In addition, they concluded that
programmers tend to think of the end-of-line as synonymous with
the end of a statement, that comments should also be terminated
by the end-of-line, etc..

However, it is not my intent to prove that side-effect operators
are bad.  I was only pointing out that, contrary to the claim
made by the previous article, the value of side-effect operators
was _NOT_ "well established".  In fact, I have found no articles
in _any_ journals which come to a conclusion that such operators
are anything other than detrimental.  The author of the article
in this newsgroup who originally made the claim has already
written email to me admitting that he had used the phrase "well
established" informally and that he was not even aware that any
research had been done on the issue.

Unless you have evidence to the contrary, I think you will have
to agree that the value of such operators is at best a subjective
assessment and is _not_ "well established".

jlg@lanl.gov (Jim Giles) (10/23/89)

From article <1989Oct21.071319.8839@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer):
> [...]                           The whole purpose of && and || is to force
> conditional evaluation, and hence evaluation order.

No, the effect these operators have on evaluation is only part of their
"whole purpose".  The also happen to be infix operators which invoke
boolean functions of two arguments.  The functions are, mathematically,
commutative and associative.  It is not, necessarily, a good idea for
the language to supress these characteristics - you loose a considerable
number of opportunities to optimize.  Some studies I've seen in the
literature recommend that the boolean operators should _not_ force
evaluation order.  I have no particular opinion on this issue except
that I am not satisfied with the loss optimization, but I wouldn't be
satisfied without a way to force order either - can't have both (or
can you?  I know of an experimental language with both).

> [...]                                              I have no objection
> to operators whose specific purpose is to force order, when they are
> broadly useful.  [...]                                                 

It is obviously a completely subjective question about what order forcing
syntax is "broadly useful".  As I've pointed out numerous times in this
discussion, I favor giving the user the option - at least - of explicitly
specifying the order of evaluation.  The specification of the C standard
in such a way that I _cannot_ force explicit evaluation order without
sacrificing efficiency and readibility is what I object to.

jlg@lanl.gov (Jim Giles) (10/23/89)

From article <1989Oct21.072905.9039@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer):
> In article <14102@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>>If it involves compromises of correctness, the language is not worth
>>pursuing...
> How can you possibly bear to use floating-point arithmetic, then?  No
> floating-point representation on any actual machine correctly implements
> the real numbers (despite misuse of the word "REAL" in Fortran). [...]

Floating point arithmetic implements, on any given machine, a well defined
set of rational numbers as well as an algebra of operations on that set.
It is possible to implement _stable_ algorithms for this set of numbers
which are useful in many applications.  This is not simple, but as it is
a very _valuable_ thing to do, it is well worth pursuing.  If this
numerical approach compromises correctness (either by not using stable
algorithms, or leaving the reagon of stability) then it is indeed a waste
of effort.

> [...]                 The reasoning required for this is orders of
> magnitude more complex than anything needed to deal with C's compromises.

A strange claim since C contains the self-same problems with floating-point
as any other modern programming language.  More, in fact!  C doesn't contain
a mechanism for forcing the evaluation order of an expression.  Seems like 
we've just been discussing this.

> Most Fortran programmers, of course, either don't bother at all or use
> what Ric Hehner has dubbed "engineering induction":  "if it works for
> n = 1, 2, and 3, that's good enough for me".

Gee, I don't know _any_ programmers that use the above claimed 'induction'.
Most scientific programmers I know are very concerned about the stability
of their algorithms.  Most programming effort in Fortran seems to be
concerned with this.

jlg@lanl.gov (Jim Giles) (10/23/89)

From article <11369@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
> [...]
> You should of course draw your own conclusions, even if they're
> based on faulty evidence or reasoning, but there is no need to rant
> about C in this newgroup.  Do that in some comparative programming
> languages newsgroup instead.

Very well done.  This is exactly the _REAL_ reason that C is spreading
so quickly.  You _assert_ that C is powerful, portable, easy to use,
easy to learn, etc..  Anyone who disagrees is diverted to some other
forum (together with the claim that his objections are "faulty evidence
or reasoning").  The main (almost exclusive) reason C spreads to some
sites is that the _management_ begins to believe all the hype and
decides to _require_ conversion.

Well, I think this is exactly the right forum for discussion about the
failings of C just as it's the right forum for any other discussion of
the language.  Not only is this one of the places where unfounded
assertions of C's capabilities are abundant, but this is also the
place where the real truth, in the form of constant bickering and
disagreement about the meaning of C, is to be found.  If C were
so well designed, there wouldn't be such a constant raft of questions
and discussions about the meaning of various features.  Even the
so-called "gurus" have disagreements about the nature of presumably
well-defined parts of the language.  Finally, it is a forum which
is read by quite a large number of novice programmers who deserve
better than to see only one side of the issue.

ok@cs.mu.oz.au (Richard O'Keefe) (10/23/89)

From article <1989Oct21.071319.8839@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer):
> [...]                           The whole purpose of && and || is to force
> conditional evaluation, and hence evaluation order.
In article <14106@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
> No, the effect these operators have on evaluation is only part of their
> "whole purpose".  The also happen to be infix operators which invoke
> boolean functions of two arguments.  The functions are, mathematically,
> commutative and associative.  It is not, necessarily, a good idea for
> the language to supress these characteristics - you lose a considerable
> number of opportunities to optimize.

C does not "suppress" the mathematical properties of conjunction and
disjunction.  It provides operators which _do_ have those properties,
and control flow operators which _don't_.  It is reasonable to say,
then, that the purpose of && and || is to force evaluation order,
because if you _don't_ want to force a particular evaluation order
you can use & and |.  Honesty compells me to admit that the two C
compilers I just checked on a 68020 don't actually do a good job of
optimising (i <= j) & (j <= k), largely because the 680x0 s<cc>
instructions generate a 0x00 or 0xFF *byte* result and these compilers
would much rather not generate an "and.b" so they do some pointless
conversion to long.  But there is no reason why a C compiler _couldn't_
generate good code for & and |.

If you want functions with guaranteed argument evaluation order, try
FORTH and PostScript.

exspes@gdr.bath.ac.uk (P E Smee) (10/23/89)

In article <6591@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>
>	I = RAND(very carefully designed seed)
>	CALL HOOPY(RAND(0), RAND(0), RAND(0))
>
>Will this [FORTRAN] program produce the same output on different machines? 
>Is this guaranteed?

NO.  See section 6.6.2 of the Standard.  Why isn't this in the FORTRAN group?
-- 
 Paul Smee               |    JANET: Smee@uk.ac.bristol
 Computer Centre         |   BITNET: Smee%uk.ac.bristol@ukacrl.bitnet
 University of Bristol   | Internet: Smee%uk.ac.bristol@nsfnet-relay.ac.uk
 (Phone: +44 272 303132) |     UUCP: ...!mcvax!ukc!gdr.bath.ac.uk!exspes

davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/23/89)

In article <14100@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
|  From article <11362@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
|  > In article <20685@usc.edu> blarson@basil.usc.edu (bob larson) writes:
|  >>Perhaps an analogy would help.
|  > 
|  > Then again, perhaps not.
|  > I sure didn't think it helped clarify what we were talking about.
|  
|  We agree on something!  I didn't think tha analogy helped either.

  I think you should go back and reread the "analogy." I think that it
might be better called a parable, and if you look to see what it has to
do with C, you will see a lot of net.people there. I thought he was
pulling my chain, but I have been out of this topic. Pity it was too
subtle for those it was meant to parody.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
"The world is filled with fools. They blindly follow their so-called
'reason' in the face of the church and common sense. Any fool can see
that the world is flat!" - anon

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/23/89)

In article <14106@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>From article <1989Oct21.071319.8839@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer):
>> the whole purpose of && and || is to force
>> conditional evaluation, and hence evaluation order.
>No, the effect these operators have on evaluation is only part of their
>"whole purpose".  The also happen to be infix operators which invoke
>boolean functions of two arguments.  The functions are, mathematically,
>commutative and associative.  It is not, necessarily, a good idea for
>the language to supress these characteristics - you loose a considerable
>number of opportunities to optimize.  Some studies I've seen in the
>literature recommend that the boolean operators should _not_ force
>evaluation order.  I have no particular opinion on this issue except
>that I am not satisfied with the loss optimization, but I wouldn't be
>satisfied without a way to force order either - can't have both (or
>can you?  I know of an experimental language with both).

Obviously Henry knows that they are Boolean operators.
He just as obviously meant that the whole purpose of the
short-circuit specification for these operators is to etc. etc.

The mathematical formalisms to which you allude do not deal with
side effects, which is the only thing that makes evaluation order
an issue.  In spite of appearances, general-purpose programming
languages do NOT implement mathematics, so arguments about how
mathematicians do things are usually not helpful.

In the total context of C as an integrated programming language,
the short-circuit nature of the && and || operators is very
valuable.  That is undoubtedly evident to any observant experienced
C programmer.

In any case, there is no point in arguing about it here.  These
are fundamental attributes of C that are not going to be changed.
One can learn to exploit them (or, in your case, perhaps, simply
to deal with them), but discussion about whether what is, should
be, are a waste of time.

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/23/89)

In article <14108@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>The main (almost exclusive) reason C spreads to some
>sites is that the _management_ begins to believe all the hype and
>decides to _require_ conversion.

Perhaps this sheds some light on YOUR situation and helps explain
why you're so dead-set against C.  If you can neither reason with
your management nor learn to live with their decisions, you could
get a job elsewhere.  If the whole world seems to be involved in
a conspiracy to force C on you, then you have more serious problems.

Most C programmers that I know chose to use C without any prompting
from management.  Hell, our management isn't qualified to choose
programming languages for us.

peter@ficc.uu.net (Peter da Silva) (10/23/89)

In article <14104@lanl.gov> jlg@lanl.gov (Jim Giles) blathers:
> 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).

OK, so in FORTRAN the calling sequence is undefined, and in addition
you're not allowed to write any code where that matters. That's a
bloody great improvement.

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

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. In Fortran, you're just
not allowed to do that. In C, you can do it but your code may not be
portable. You have to watch out for dependencies among the arguments.

You may be confused because in Fortran the only way an expression can have
side effects is if it involves a function call.

Here's another question:

	In FORTRAN:

		INTEGER I, J
		INTEGER GETCH ! Returns next byte at input.
		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?

C makes these guarantees.
-- 
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
"I feared that the committee would decide to go with their previous        'U`
 decision unless I credibly pulled a full tantrum." -- dmr@alice.UUCP

peter@ficc.uu.net (Peter da Silva) (10/23/89)

In article <14105@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
> Unless you have evidence to the contrary, I think you will have
> to agree that the value of [side effect] operators is at best a subjective
> assessment and is _not_ "well established".

The question of side-effect operators is really a question of side-effects
in expressions. If you ban side-effects in expressions, you've got to ban
side effects in functions as well. Not just declare them, ban them altogether.
It's obviously too dangerous to allow propgrammers to use anything other
than pure functions.

If you believe this I'd suggest you look into topics like object-oriented
languages, languages with generators, and so on. There you will find your
established literature supporting side-effects.

And in the meantime you can write "SAFE C" programs, merely by adhering to
the restrictions inherent in your preferred languages. Everyone is happy.
And we can go back to important questions like acessing the VGA from Turbo
C.
-- 
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
"I feared that the committee would decide to go with their previous        'U`
 decision unless I credibly pulled a full tantrum." -- dmr@alice.UUCP

henry@utzoo.uucp (Henry Spencer) (10/23/89)

In article <14105@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>However, the paper I reference made a detailed study of TOPPS vs.
>TOPPS2...

Actually, that's the paper you *didn't* reference.  If, as I would guess,
it's Gannon et al, note that Gannon's thesis supplies rather more detail.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

jlg@lanl.gov (Jim Giles) (10/24/89)

From article <1989Oct22.184222.29580@twwells.com>, by bill@twwells.com (T. William Wells):
> Followups have been directed to alt.flame.

Followups have been redirected here!!  I don't read alt.flame.

> You see, if you knew beans about C optimizers, [...]

And you do, I suppose?  Then you can explain why you think C is
faster than other languages in spite of the fact that it is inherently
harder to optimize.  Once a program has been parsed and is represented
by an abstract syntax tree (or some other intermediate representation)
it is nearly impossible to tell what language the original source was
in - except C which has more aliasing and potential dependencies than
most other languages.  Also, C's character processing is less efficient
as well.  In those respects that are important to compiling, C is
nearly identical to most other imperative languages.  In those respects
where it differs, it is harder to optimize.

> You may have knowledge, but you are lacking in C wisdom.
                                                 ^^^^^^^^
Is that the peculiar mental condition which prevents you from discussing
an issue without resorting to abuse?

desj@idacrd.UUCP (David desJardins) (10/24/89)

From article <11388@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
> The mathematical formalisms to which you allude do not deal with
> side effects, which is the only thing that makes evaluation order
> an issue.

   I don't agree with this.  Efficiency can also be a major issue.  It
makes sense to say that you want one expression evaluated first if you
expect that the second one is more expensive to evaluate and/or less
likely to be needed.  (This is obviously something that an optimizer
may not be able to determine.)  This feature is one of the annoying
things which FORTRAN is missing.

   -- David desJardins

jlg@lanl.gov (Jim Giles) (10/24/89)

From article <11388@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
> [...]
> In the total context of C as an integrated programming language,
> the short-circuit nature of the && and || operators is very
> valuable.  [...]

I have still not made my point, but I'm close.  Of course the short
circuit nature of these operators is valuable.  If they didn't
short circuit, you would still need a way of providing that functionality.
As I said previously, some researchers have maintained that this
functionality should be provided some other way - leaving the logical
connectives to their usual mathematical purity.  I have said that I
have no particular opinion on this.

However, my _POINT_ was that, if the short circuit nature of these
operators is valuable, then there might also be other contexts where
user control of expression evaluation order might _ALSO_ be valuable!
C doesn't provide such other mechanisms - WHY NOT?!?!?!?

> One can learn to exploit them (or, in your case, perhaps, simply
> to deal with them), but discussion about whether what is, should
> be, are a waste of time.

Why?  Is C set in concrete?  What about C++ ???   How about (C++)++ ?
Why are you so defensive about possible change - maybe even improvement?

jlg@lanl.gov (Jim Giles) (10/24/89)

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!  If the
_expressions_ used as arguments have dependent side effects, if a compiler
is capable of optimizing the order of argument evaluation in any useful
way (that is, both correct and efficient), than that compiler is _also_
capable of detecting the dependencies and enforcing some fixed evaluation
order on them.  The C standard would loose _NO_ useful optimization
potential by specifying the _effective_ order in which arguments were
to be evaluated.

> You may be confused because in Fortran the only way an expression can have
> side effects is if it involves a function call.

I am obviously _not_ confused in that manner.  Everyone seems to assume
any opponent of C must be some reactionary neanderthal committed to
Fortran.  Anyone who reads comp.lang.fortran can vouch for the fact
that I find a good number of things wrong with Fortran!  In fact, what
I really want is for programming language technology to _advance_!
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.

> [...]
> 		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?
> C makes these guarantees.


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

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

Once again, your assumption that I believe Fortran to be perfect is
not correct.  As I've already pointed out, it should be possible to
explicitly specify whether a function has side effects and the
language definition should be scrupulously specific about the evaluation
order (as well as _whether_ they are evaluated) in the presence of
such side effects.

grogers@sushi.uucp (Geoffrey Rogers) (10/24/89)

In article <14104@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>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.
>
>                    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).  

It is! Where does it say that in the FORTRAN 77 standard? Here what the 
Fortran 77 standard says:

6.6.2 Order of Evaluation of Functions.  If a statement contains more than one
function reference, a processor may evaluate the functions in any order, except
for logical IF statements and a function argument list containing function
references. For example, the statement

		Y = F(G(X))

where F and G are functions, requires G to be evaluated before F is evaluated.

In a statement that contains more than one function reference, the value
provided by each function reference must be independent of the order chosen
by the processor for evaluation of the function reference.

From this I would say that the first calling sequence is legal no matter
what the side effects are from the evaluation order of the functions. 

Also note that the second calling sequence is illegal, because you are 
generating an illegal form of aliasing. 

From this I would say that FORTRAN is just as ambigous as C. If you are
going to compare C to other languages such as FORTRAN, please know what
in the standard before you say what is or isn't legal.

Geoffrey C. Rogers			"Whose brain did you get?"
{sun,uunet}!convex!grogers		"Abie normal!"
grogers@convex.com

jlg@lanl.gov (Jim Giles) (10/24/89)

From article <6638@ficc.uu.net>, by peter@ficc.uu.net (Peter da Silva):
> If you believe this I'd suggest you look into topics like object-oriented
> languages, languages with generators, and so on. There you will find your
> established literature supporting side-effects.

No, I will find literature about languages which have side effects built
into their expressions.  I will not find literature here that establishes
that it is a good idea to do so.  It is particularly hard to do such
research and few have attempted it.  So far, side effects haven't fared
too well.  Since I do considerable research on language design, I have
probably read most of the books/articles that you are recommending - as
well as others.

However, if you really want my opinion on this:  the programming language
should have no built-in operators with side effects and should have no
intrinsic functions with side effects.  The user can define functions
and operators to do anything he wants - side effects or not.

peter@ficc.uu.net (Peter da Silva) (10/24/89)

In article <14110@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
> Why?  Is C set in concrete?  What about C++ ???   How about (C++)++ ?
> Why are you so defensive about possible change - maybe even improvement?

Because we have seen what happened to X3J3 and Fortran 8x.
-- 
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)

peter@ficc.uu.net (Peter da Silva) (10/24/89)

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)

keith@sunpix.UUCP ( Sun Visualization Products) (10/25/89)

In article <14106@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
# <boolean operators should or shouldn't force evaluation order deleted>
#I have no particular opinion on this issue except
#that I am not satisfied with the loss optimization, but I wouldn't be
#satisfied without a way to force order either - can't have both (or
#can you?  I know of an experimental language with both).

Ada supports AND and OR for non short-circuit, and AND THEN and OR ELSE
for short-circuit.

Personally, I find supporting both the best, but if a language is
only going to support one, I prefer the short-circuit version.

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/25/89)

In article <14109@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>From article <1989Oct22.184222.29580@twwells.com>, by bill@twwells.com (T. William Wells):
>> You see, if you knew beans about C optimizers, [...]
>And you do, I suppose?  Then you can explain why ...
>> You may have knowledge, but you are lacking in C wisdom.
>Is that the peculiar mental condition which prevents you from discussing
>an issue without resorting to abuse?

It looks to me like Bill Wells was merely stating the facts that are
apparent to him.  Your inane comments about C's character processing
being less efficient (than in other programming languages) back him
up in his assessment.  For many years one could find systems that
had both Fortran and C compilers implemented using precisely the
same code generation and optimization technology, and on those
systems typical systems programs involving heavy character operations
(e.g. "grep") ran much faster when coded in C than when coded in
Fortran.  I actually tried the experiment once.

Please redirect your flames back to alt.flame.

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/25/89)

In article <14110@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>user control of expression evaluation order might _ALSO_ be valuable!
>C doesn't provide such other mechanisms - WHY NOT?!?!?!?

Sure it does, you just have to know how to obtain the effect using
what the language provides.

>> discussion about whether what is, should be, are a waste of time.
>Why?  Is C set in concrete?

Actually, yes it is, for things like this.

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/25/89)

In article <483@idacrd.UUCP> desj@idacrd.UUCP (David desJardins) writes:
-From article <11388@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
-> The mathematical formalisms to which you allude do not deal with
-> side effects, which is the only thing that makes evaluation order
-> an issue.
-   I don't agree with this.  Efficiency can also be a major issue.  It
-makes sense to say that you want one expression evaluated first if you
-expect that the second one is more expensive to evaluate and/or less
-likely to be needed.

You must have missed my point; check out the article to which I was
replying, then re-read my response.

I wasn't talking about whether or not control of evaluation order
is DESIRABLE.  The case you argue is one that I basically agree with.

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/25/89)

In article <2493@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes:
>you can use & and |.

& and | aren't really Boolean operators in the normal use of the term
in the context in which this arose; they're bitwise integer operators.

Obviously one could pour more and more operators into a language.
People already complain about C having too many..

jlg@lanl.gov (Jim Giles) (10/25/89)

From article <2320@convex.UUCP>, by grogers@sushi.uucp (Geoffrey Rogers):
> In article <14104@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>>From article <6613@ficc.uu.net>, by peter@ficc.uu.net (Peter da Silva):
>>> [ in Fortran,
>>> 	CALL SUBR(FUNC, FUNC)
>> [... I said statement was illegal in Fortran is FUNC has side effects ...]
> It is! Where does it say that in the FORTRAN 77 standard? Here what the 
> Fortran 77 standard says:
" 6.6.2 Order of Evaluation of Functions. [...]                                 
" In a statement that contains more than one function reference, the value
" provided by each function reference must be independent of the order chosen
" by the processor for evaluation of the function reference.
> 
> From this I would say that the first calling sequence is legal no matter
> what the side effects are from the evaluation order of the functions. 

And you'd be wrong!  The quoted part of the standard clearly states that
if the value that FUNC returns is effected by the order of the two calls,
the statement is illegal.  Such a statement doesn't conform to a "must"
clause in the standard!

To make this more clear, suppose the first call to FUNC returns 0.5 and
the second returns 1.5.  Clearly CALL SUBR(0.5,1.5) is different than
CALL SUBR(1.5,0.5).  The Fortran standard prohibits the original form
of the call specifically to allow the optimization without ambiguity.

< [...]                                              If you are
< going to compare C to other languages such as FORTRAN, please know what
< in the standard before you say what is or isn't legal.

I would say the same to you.  Especially since I had already quoted
that part of the standard in a previous posting.

To get this back to a C related subject: please note (again) that I
do _not_ recommend the Fortran rules as better than C (not for this
issue anyway :-).  The above Fortran rule is too restrictive.  The
C rule is too permissive.  The middle ground would give the user
more control _and_ better insure the correctness of the code.

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/25/89)

In article <6658@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>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.

Why not give him the benefit and say he's trying to design an
automobile, while the rest of us are busy trying to use the
mechanical horses that we're currently stuck with.  Wish him
luck and bon voyage.

jlg@lanl.gov (Jim Giles) (10/25/89)

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.

jlg@lanl.gov (Jim Giles) (10/25/89)

From article <11398@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
> It looks to me like Bill Wells was merely stating the facts that are
> apparent to him.  Your inane comments about C's character processing
> being less efficient (than in other programming languages) back him
> up in his assessment.  

I don't see how.  C character strings are null terminated rather
that keeping the length of the string explicitly.  The result of this
is that hardware with specialized instructions for character processing
cannot be used as efficiently in C as with other languages.  The C
strings always have to be prescanned to determine their length before
the operation you are _really_ interested in can be performed.

I have character manipulations routines on the Cray which are
asymptotically faster than one clock per character for such operations
as translating from lower- to upper-case, searching for delimiters,
etc.  To use them with C requires a prescan for the null or the
algorithm must be rewritten to scan for the null simultaneously
with other activities - at least a 50% penalty either way.

> [...]                   For many years one could find systems that
> had both Fortran and C compilers implemented using precisely the
> same code generation and optimization technology, and on those
> systems typical systems programs involving heavy character operations
> (e.g. "grep") ran much faster when coded in C than when coded in
> Fortran.  I actually tried the experiment once.

For many years, C was notorious for not being very well optimized
and the Fortran that accompanied was famous for being _really_ bad.
They had the same code generation and optimization technology because
the Fortran compiler used the C backend - which was not well designed
for the type of optimization Fortran requires.

Furthermore, you are still _assuming_ that I am defensive about
Fortran.  I never claimed that Fortran had _really_fast_ character
handling capabilities - only that some languages other than C could
be expected to outdo C in that regard.  (However, if Fortran's
string handling is slower than C it is for some other reason than
what I discussed above.)

> Please redirect your flames back to alt.flame.

When I decide to flame someone perhaps I will.  In the meantime, the
redirection of articles will only serve you rhetorical purpose of
having the last word on the issue.  I've no objections to your having
the last word - as long as what you say is both true and fair.

diamond@csl.sony.co.jp (Norman Diamond) (10/25/89)

In article <6591@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:

>>	I = RAND(very carefully designed seed)
>>	CALL HOOPY(RAND(0), RAND(0), RAND(0))
>>
>>Will this [FORTRAN] program produce the same output on different machines? 
>>Is this guaranteed?

In article <1989Oct23.094426.4105@gdt.bath.ac.uk> exspes@gdr.bath.ac.uk (P E Smee) writes:

>NO.  See section 6.6.2 of the Standard.  Why isn't this in the FORTRAN group?

Mr. da Silva's question concerns the relative defects of Fortran and C.
There is no comp.lang.c-vs-fortran, and no comp.lang.relative-defects.
Why is comp.lang.fortran more suitable than comp.lang.c?

-- 
Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work)
  Should the preceding opinions be caught or     |  James Bond asked his
  killed, the sender will disavow all knowledge  |  ATT rep for a source
  of their activities or whereabouts.            |  licence to "kill".

ok@cs.mu.oz.au (Richard O'Keefe) (10/25/89)

In article <6658@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes:
>     DATA I /0/
>     J = I * GETCH(5)
>     J = 0 * GETCH(6)

> Is this legal?
Yes (CF=0.9)
> Is it guaranteed that GETCH(5) will be evaluated?
If I is not modified elsewhere in the subprogram, no it is not.
A Fortran compiler is allowed to exploit identities such as 0*X = 0
> Is it guaranteed that GETCH(6) will be evaluated?
No.

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

In the Fortran equivalent
	IF (GETCH(5) .AND. GETCH(6)) ...
either operand may be evaluated first, and the other may or may not
be evaluated depending on the outcome and the compiler-writer's choice.
This is what it _means_ to exploit the mathematical properties of "and"
as Giles recommends.

ok@cs.mu.oz.au (Richard O'Keefe) (10/25/89)

In article <11401@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
> In article <2493@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes:
> >you can use & and |.
 
> & and | aren't really Boolean operators in the normal use of the term
> in the context in which this arose; they're bitwise integer operators.

I know perfectly well what & and | are, but if you build up expressions
out of comparisons (E1 <relop> E2), negations (using ! rather than ~),
and & and |, you can't tell the difference.  The difference only shows
up when some of the leaves have values other than 0 or 1, and with
C's comparison operators that can't happen.  It remains true that you
can *USE* & and | as versions of "and" and "or" that are commutative,
associative, &c.

ok@cs.mu.oz.au (Richard O'Keefe) (10/25/89)

In article <14115@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
> From article <11398@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
> > It looks to me like Bill Wells was merely stating the facts that are
> > apparent to him.  Your inane comments about C's character processing
> > being less efficient (than in other programming languages) back him
> > up in his assessment.  

> I don't see how.  C character strings are null terminated rather
> that keeping the length of the string explicitly.  The result of this
> is that hardware with specialized instructions for character processing
> cannot be used as efficiently in C as with other languages.  The C
> strings always have to be prescanned to determine their length before
> the operation you are _really_ interested in can be performed.

You are both right.

    C is an exceptionally good language for CHARACTER processing.
    C is a rather bad language for STRING processing.

I have an anecdote:  a friend of mine spent a couple of months writing a
fairly "batch" editor in PL/I to run on an IBM mainframe.  He made extensive
use of PL/I's CHARACTER(LENGTH) VARYING, that's what the type is for, right?

(BEGIN DIGRESSION:

    #define DclCharVar(Vbl, N) struct { \
	int curlen; \
	char curtxt[N]; \
    } Vbl = {0}    
    #define DclCharCon(Vbl, S) struct { \
	int curlen; \
	char curtxt[-1 + sizeof S]; \
    } Vbl = {-1 + sizeof S, S}
    DclCharVar(a, 20);
    DclCharCon(b, "A literal value");

    gives you roughly the same effect as

    DCL A CHAR(20) VARYING, B CHAR(15) INITIAL("A literal value");

    in PL/I, except that you're still missing the library of built in
    functions and the compiler optimisations.
END DIGRESSION)

It was extremely painful for him to do this; none of the built in functions
was quite what he wanted, and if you wrote your own string functions they
ran an order of magnitude slower than the built in ones.  (Your functions
did not exploit special hardware and the compiler didn't know how to
optimise them.)

As an exercise in learning C, I implemented the same editor on a PDP-11/60
running V6+ UNIX.  It took me 3 days to write and 2 more to debug, and
was about 12 pages long compared with my friend's 60.  It was also faster
on the 11/60 than my friend's program on an IBM 4331 (I think it was a
4331; might have been bigger).

What happened?  All things considered, I think my friend was a better
programmer than I was.  The point was that he was starting from a STRINGS
language where the built-in functions were fast but anything else was hard,
whereas I was starting from a CHARACTERS language where I was able to
synthesise precisely the operations that I needed (3 pages to define the
``string'' functions I wanted).

If you insist on seeing array-of-byte-with-NUL-terminator as *THE*
equivalent in C of strings, you are going to be in big trouble.  The
C library actually supports THREE different representations:
	unbounded-array-of-byte-with-NUL terminator  (str* functions)
	at-most-N-bytes-with-NUL-terminator-if-short (strn* functions)
	array-of-exactly-N-bytes                     (mem* functions)
VMS C programmers use a fourth representation, "descriptor", which has
extensive support in the VMS runtime library.  C provides direct
syntax for literals of only one type, but as I showed above, it isn't
hard to come up with macros to declare named constants of the other
types.  (VMS C already has such a macro for "descriptors".)

If you insist on doing text processing with strings, you are making a
pretty big mistake no matter what language you are using.  For example,
in Lisp and Prolog I have been able to reduce program costs from O(N**2)
to O(N) by switching from "string" representation of character sequences
to linked lists.  In general, it is wise to use "implicit" representations
for character sequences where you can.  Instead of constructing strings
and writing them out, construct trees of some sort and have a tree-walker
that sends out the characters without putting them in a string.

exspes@gdr.bath.ac.uk (P E Smee) (10/25/89)

In article <14110@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>
>I have still not made my point, but I'm close.  Of course the short
>circuit nature of these operators is valuable.  If they didn't
>short circuit, you would still need a way of providing that functionality.

Valuable indeed.  One of the more common subtle bugs in PL/1 programs is

    if ((ptr ^= null()) & (ptr->thing ^= value))

because PL/1 logical ops don't short circuit.  Algol may have this right,
they offer two sets of logical operators:  AND and OR which do not short
circuit; and ANDTHEN and ORELSE which do.  This gives the programmer total
control, and might be worth considering for some future version of C or
a C offspring.  Both are useful, and making either from the other in a
language which only supports one is fiddly at best.

-- 
 Paul Smee               |    JANET: Smee@uk.ac.bristol
 Computer Centre         |   BITNET: Smee%uk.ac.bristol@ukacrl.bitnet
 University of Bristol   | Internet: Smee%uk.ac.bristol@nsfnet-relay.ac.uk
 (Phone: +44 272 303132) |     UUCP: ...!mcvax!ukc!gdr.bath.ac.uk!exspes

peter@ficc.uu.net (Peter da Silva) (10/25/89)

I said, to Jim Giles:
    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.

In article <11407@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
> Why not give him the benefit and say he's trying to design an
> automobile, while the rest of us are busy trying to use the
> mechanical horses that we're currently stuck with.  Wish him
> luck and bon voyage.

Not at all. We're riding horses, because there aren't enough roads out
there good enough for cars. But they're getting there...
-- 
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)

peter@ficc.uu.net (Peter da Silva) (10/25/89)

In article <14114@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
> 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.

Compare it to X3J3.

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

I've been trying to come up with a response to this statement that is
sufficiently polite that I won't get redirected to alt.flame, while at
the same time at least vaguely expressing my reaction to this statement.
Either your comp.lang.c feed comes from an alternate universe, or you're
so irrationally opposed to the language that you're seeing things.

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

Right now the roads aren't good enough for automobiles, and we can't afford
to buy helicopters.

So, what's the systems programming language of this century? Assembler?

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

--> Is this legal?                                    [YES]

Thank you.

--> Is it guaranteed that GETCH(5) will be evaluated? [No - as far as I know]
--> Is it guaranteed that GETCH(6) will be evaluated? ["    "   "  "  "  "  ]

Is there any guarantee that either of these will not be evaluated?

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

You say that X3J11 is the only standard which allowed ambiguous constructs.

Looks like that statement is inoperative.

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

henry@utzoo.uucp (Henry Spencer) (10/25/89)

In article <14114@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>> [...]                                      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.

Let him who does not worship Fortran cast the first stone. :-)  Compared
to Fortran [789]N (or maybe it's Fivtran 9N now), ANSI C has moved along
pretty briskly and with little controversy.  And it *is* a standard
for all practical purposes, even if silly bureaucratic obstacles are
delaying the official laying-on-of-hands by ANSI.  There is no doubt
about the content any more.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

feg@clyde.ATT.COM (Forrest Gehrke,2C-119,7239,ATTBL) (10/26/89)

In article <14110@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
> From article <11388@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
> > [...]
> 
> > One can learn to exploit them (or, in your case, perhaps, simply
> > to deal with them), but discussion about whether what is, should
> > be, are a waste of time.
> 
> Why?  Is C set in concrete?  What about C++ ???   How about (C++)++ ?
> Why are you so defensive about possible change - maybe even improvement?

o


Hey! Maybe it's time to talk about adding pointers again. (;-)

Forrest Gehrke clyde!feg

jlg@lanl.gov (Jim Giles) (10/26/89)

From article <2520@munnari.oz.au>, by ok@cs.mu.oz.au (Richard O'Keefe):
>> >       if (getch(5) && getch(6)) {...}
> In the Fortran equivalent
> 	IF (GETCH(5) .AND. GETCH(6)) ...
> either operand may be evaluated first, and the other may or may not
> be evaluated depending on the outcome and the compiler-writer's choice.
> This is what it _means_ to exploit the mathematical properties of "and"
> as Giles recommends.

This is false, since I haven't _made_ a recommendation on this issue.
It is also false because I wouldn't recommend eliminating the short
circuit behaviour of && and || without also requiring the full evaluation
of all operands that _might_ cause side effects.  In other words, you are
confusing the behaviour of Fortran with the behaviour I _might_ recommend.

jlg@lanl.gov (Jim Giles) (10/26/89)

From article <6675@ficc.uu.net>, by peter@ficc.uu.net (Peter da Silva):
> In article <14114@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>> [... comments about the continuing lack of an approved C standard ...]
> Compare it to X3J3.

I dare not!  I've been accused (incorrectly) of hold C up to scrutiny
only vs. Fortran.  This, is another case in which someone else just
assumes that I will be defensive about Fortran.

But, what the hell - since you mention it.  X3J3 _has_ successfully
passed 2 previous standards.  The present revision has only gone to
two public reviews so far.  X3J11 has gone to 3 public reviews and
now faces a class action suit - they still haven't passed even one
standard!

> [... Examples like X = 0 * FUNC(Y) ...]
> You say that X3J11 is the only standard which allowed ambiguous constructs.
> Looks like that statement is inoperative.

Not at all.  The Fortran standard refers to the above behaviour as
"implementation defined".  This means that the implementation _should_
define the meaning of the expression.  Most implementations choose to
let the optimizer have free rein (and therefore, the _implementation_
is responsible for the ambiguity).  In my opinion, this doesn't meet
the requirements of standard conformance since the implementation
_should_ define the semantic meaning of the construct.

However, X3J11 will be the only ANSI language standard which _specifically_
_doesn't_ require an implementation to provide a definition of some
behaviours in order to be considered comforming.  Therefore, the ambiguity
is specifically allowed by the proposed standard.

chip@ateng.com (Chip Salzenberg) (10/26/89)

According to jlg@lanl.gov (Jim Giles):
>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.

The systems language of the OS of the century isn't the systems programming
language of the century?

Uh, right.

This person has been marked for deletion.
-- 
You may redistribute this article only to those who may freely do likewise.
Chip Salzenberg at A T Engineering;  <chip@ateng.com> or <uunet!ateng!chip>
"'Why do we post to Usenet?'  Naturally, the answer is, 'To get a response.'"
                        -- Brad "Flame Me" Templeton

bagpiper@pnet02.gryphon.com (Michael Hunter) (10/26/89)

gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
>In article <14108@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>>The main (almost exclusive) reason C spreads to some
>>sites is that the _management_ begins to believe all the hype and
>>decides to _require_ conversion.
>Most C programmers that I know chose to use C without any prompting
>from management.  Hell, our management isn't qualified to choose
>programming languages for us.

Unfortunately they DON'T always think that!  Worse, is the governments
insistence that EVERYTHING be written in ADA and they can handle controlloing
the evolution of the language.....!!

Mike Hunter - Box's and CPU's from HELL: iapx80[012]86, PR1ME 50 Series, 1750a
UUCP: {ames!elroy, <routing site>}!gryphon!pnet02!bagpiper
INET: bagpiper@pnet02.gryphon.com

ok@cs.mu.oz.au (Richard O'Keefe) (10/26/89)

In article <14123@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
: From article <2520@munnari.oz.au>, by ok@cs.mu.oz.au (Richard O'Keefe):
: > This is what it _means_ to exploit the mathematical properties of "and"
: > as Giles recommends.
 
: This is false, since I haven't _made_ a recommendation on this issue.

I apologise for misrepresenting Giles on this issue.  Unfortunately,
I haven't been keeping copies of his articles, so I was unable to quote
him accurately.  He did, however, at one stage, attack "&&" and "||".

bbadger@x102c.harris-atd.com (Badger BA 64810) (10/27/89)

In article <1989Oct21.071319.8839@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <14102@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
[...]
>
>>...  Presumably, if C
>>made argument evaluation in function calls "well-defined", you would
>>would have no qualms depending on their order either...
>
>Your presumption is incorrect.  The whole purpose of && and || is to force
>conditional evaluation, and hence evaluation order.  I have no objection
>to operators whose specific purpose is to force order, when they are
>broadly useful.  I do have considerable objection to code that depends
>on evaluation order *without* putting the reader on notice of it by
>explicitly using forcing operators.
>-- 
>A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
>megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

I'm not sure if you're saying that a known order of evaluation (OOE) is a 
*bad* idea, or that you would rather accept an undefined order so that 
all possible compiler optimizations which may depend on the OOE would be 
legalized.

There are languages which exploit either a free OOE or a fixed OOE to good 
effect.  

Edsker Djikstra's ``guarded command language'' from ``A Discipline of
Programming'' has a non-deterministic form of iteration statement
with a syntax something like:
	DO 
	[] guard1 -> stmt1a; stmt1b;
	[] guard2 -> stmt2a; stmt2b;
	OD
where ANY one of the statement lists with TRUE guards will be executed
and then the guards re-evaluated.  The DO-OD terminates when no guards 
remain true.  Dr. Djkstra gives some examples where it is actually 
*easier* to prove the algorithm correct if a definite order of evaluation
does not need to be taken into account.  

On the other hand, in Icon, order of evaluation  of argument lists, is 
precisely defined as left-to-right.  This fact, drives the sequencing of 
the ``mutual evaluation'' of all the arguments.  Mutual evaluation may
result in multiple evaluation of the arguments by backtracking through 
the results generated by each argument until all arguments can be satisfied
simultaneously.

The design of C mostly favors a simple compiler design which is free
to evaluate arguments in any order which is convenient for the
compiler writer, rather than serving any semantic purpose at all. 
It is fair to say that this no great asset to programmers who must 
now guard against an unnoticed argument order dependency.

(IMHO) The classic C/UNIX philosophy, it's better to have something
available that *can* work and just be careful not to shoot yourself in
the foot.  Of course, this occasionally fools the unwary and is a 
source of many ``gotchas''.


    -----	-	-	-	-	-	-	-	----
Bernard A. Badger Jr.	407/984-6385          |``Get a LIFE!''  -- J.H. Conway
Harris GISD, Melbourne, FL  32902             |Buddy, can you paradigm?
Internet: bbadger%x102c@trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.

bph@buengc.BU.EDU (Blair P. Houghton) (10/27/89)

In article <2446@cbnewsl.ATT.COM> feg@clyde.ATT.COM writes:
>In article <14110@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
>> From article <11388@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
>> > One can learn to exploit them (or, in your case, perhaps, simply
>> > to deal with them), but discussion about whether what is, should
>> > be, are a waste of time.
>> 
>> Why?  Is C set in concrete?  What about C++ ???   How about (C++)++ ?
>> Why are you so defensive about possible change - maybe even improvement?
>
>Hey! Maybe it's time to talk about adding pointers again. (;-)

I've even got the semantics worked out.  ( A :-) for effect, and
a :-| because it's _absolutely_true_)

				--Blair
				  "It's on a post-it note
				   ...SOMEwhere around here..."

rob@raksha.eng.ohio-state.edu (Rob Carriere) (10/27/89)

In article <14113@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
[on evaluation order of function arguments]
>[...] The above Fortran rule is too restrictive.  The
>C rule is too permissive.  The middle ground would give the user
>more control _and_ better insure the correctness of the code.

Could you _please_ explain why you think this is important at all?  Throwing
interacting side effects into a function call is one very good way to confuse
the sh*t out everybody, including the poor person who has to maintain the
code.  If you need side effects in your arguments and they interact, assign to
variables first, that way it is clear what you're doing.  If your compiler
doesn't like sequences like that, send your vendor oxidizing mail.  As for
readability, I think any problems in that department are more due to fact that
you are trying to do something messy and very complex than to any language
deficiencies.  Besides, just how often does it happen?

SR

dg@lakart.UUCP (David Goodenough) (10/27/89)

exspes@gdr.bath.ac.uk (P E Smee) sez:
> .....  Algol may have this right,
> they offer two sets of logical operators:  AND and OR which do not short
> circuit; and ANDTHEN and ORELSE which do.  This gives the programmer total
> control, and might be worth considering for some future version of C or
> a C offspring.  Both are useful, and making either from the other in a
> language which only supports one is fiddly at best.

However, those of us that know De Morgan's laws can get by very neatly
with ! & | and a couple of preprocessor macros for non-short circuiting
operators.

#define and(x, y) (!((!(x)) | (!(y))))
#define or(x, y)  (!((!(x)) & (!(y))))

This does rather assume that your optimizer is up to the job, but then
that's a whole other thread. Also, as someone once said "Never sacrifice
clarity for efficiency" (gets +6 ring of fire resistance ready :-) )
-- 
	dg@lakart.UUCP - David Goodenough		+---+
						IHS	| +-+-+
	....... !harvard!xait!lakart!dg			+-+-+ |
AKA:	dg%lakart.uucp@xait.xerox.com			  +---+

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/28/89)

In article <14114@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>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.

What "class-action suit"?  This is the first I've heard about it.

The three public reviews were a normal part of the process, to which you
could have contributed if you had condescended to do so.  I have no record
of you having submitted your comments when they were being solicited.

X3J11 and X3 have both approved the proposed ANSI C standard from a
technical perspective (analogous approvals have been occurring in
ISO WG14).  The only delay is to give one individual with a grudge
a hearing on procedural issues.  Nobody I know of expects ANSI to
side with that individual.  Thus, we know at this point precisely
what the final ANSI standard for the C programming language is
expected to look like technically.  The delay is purely bureaucratic.
Correspondingly, vendors have been proceeding to implement the Standard
and application developers have been coding with Standard C taken into
account, and books based on the Standard have already been published.

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

I would be interested in actual quotations to that effect.  I don't
recall ANYbody here saying that C is the language of the future.
It is definitely an important language of the present, recent past,
and near term, though.

>... I would dispute the claim
>that C is _the_ systems programming language of this century.

Hey, so would I.  It's certainly the most important systems programming
language of the 1976-1990 time frame, if for no other reason than that
UNIX was implemented primarily in C.  (But there are other reasons too.)

But again, who gives a rat's ass about this?  Claims are a dime a dozen,
probably cheaper.  I could claim that ESPOL was the best systems
programming language invented so far, or BLISS, or Modula-2, or Eiffel,
but WHAT DOES THAT HAVE TO DO WITH C?

hamish@unisoft.UUCP (Piccadilly Line Exile) (10/28/89)

In article <4672@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. "Don't mention
				the P O I N T E R S" Houghton) writes:
>In article <2446@cbnewsl.ATT.COM> feg@clyde.ATT.COM writes:
>>
>>Hey! Maybe it's time to talk about adding pointers again. (;-)
>
>I've even got the semantics worked out.  ( A :-) for effect, and
>a :-| because it's _absolutely_true_)
>
>				--Blair

Yeah!! Quick!! Post it!! God, I'm starting to feel anticipatory shivers
of delight already.... (Maybe we could work together on an entire
alternate universe of C semantics...).

	Hamish (feeling nostalgic)
-----------------------------------------------------------------------------
Hamish Reid             UniSoft Corp, 6121 Hollis St, Emeryville CA 94608 USA
+1-415-420-6400         hamish@unisoft.com,          ...!uunet!unisoft!hamish

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/28/89)

In article <14115@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>I don't see how.  C character strings are null terminated rather
>that keeping the length of the string explicitly.

Both approaches have their relative advantages and disadvantages.
Efficiency depends very much on the specific hardware support;
some architectures work quite well with delimited strings and
others work better with byte counts.

At least with C you have the option of implementing your own counted
strings if you prefer them.

henry@utzoo.uucp (Henry Spencer) (10/28/89)

In article <2816@trantor.harris-atd.com> bbadger@x102c.harris-atd.com (Badger BA 64810) writes:
>>... I have no objection
>>to operators whose specific purpose is to force order, when they are
>>broadly useful.  I do have considerable objection to code that depends
>>on evaluation order *without* putting the reader on notice of it by
>>explicitly using forcing operators.
>
>I'm not sure if you're saying that a known order of evaluation (OOE) is a 
>*bad* idea, or that you would rather accept an undefined order so that 
>all possible compiler optimizations which may depend on the OOE would be 
>legalized.

To clarify:  my view is that order-dependent code in C is almost always
a bad idea, and should be avoided like the plague, barring one or two
specialized constructs like && whose mission in life is order control.
If one is sensible and avoids order-dependent code, there is no reason
to forbid compiler reordering, and it does give more opportunity for
optimization.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/28/89)

In article <21461@gryphon.COM> bagpiper@pnet02.gryphon.com (Michael Hunter) writes:
>gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
>>Most C programmers that I know chose to use C without any prompting
>>from management.  Hell, our management isn't qualified to choose
>>programming languages for us.
>Unfortunately they DON'T always think that!

Sure, there are lots of idiots in this world that won't listen to reason.
You aren't being FORCED to work for them, are you?
I've changed jobs before over disagreements about technical management.

>Worse, is the governments insistence that EVERYTHING be written in ADA
>and they can handle controlloing the evolution of the language.....!!

Ada was a highly political development.  It mostly impacts those who
provide deliverable software systems under contract to the U.S. Federal
government.  Initially, this was pretty much limited to embedded systems.

Ada was an attempt to solve an educational and managerial problem
by imposing technical constraints.  Naturally that hurts more than
it helps.

It may be interesting to note that we refuse to use Ada here for our
own purposes.  (Very little of our software development is contracted
out).  It would have utterly ruined our operation if we had had to
comply with the Ada "requirement".  Fortunately, waivers weren't very
hard to obtain.  They're more difficult to get now, so falling back to
"Plan B" (ignore the demands) is becoming a more attractive alternative.

peter@ficc.uu.net (Peter da Silva) (10/28/89)

Perhaps it's time for a C-FUTURES mailing list?

If someone cares to send me some mailing-list support programs, I'll
endeavour to set things up.
-- 
`-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.hackercorp.com>.
 'U`  --------------  +1 713 274 5180.
"That particular mistake will not be repeated.  There are plenty of mistakes
 left that have not yet been used." -- Andy Tanenbaum (ast@cs.vu.nl)

bph@buengc.BU.EDU (Blair P. Houghton) (10/28/89)

In article <2546@unisoft.UUCP> hamish@unisoft.UUCP (Piccadilly Line Exile) writes:
>In article <4672@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. "Don't mention
>the P-O-I-N-T-E-R-S" Houghton) writes:

Moooooooomeeeeee!  What does this word spaill?

>>In article <2446@cbnewsl.ATT.COM> feg@clyde.ATT.COM writes:
>>>
>>>Hey! Maybe it's time to talk about adding pointers again. (;-)
>>
>>I've even got the semantics worked out.
>
>Yeah!! Quick!! Post it!! God, I'm starting to feel anticipatory shivers
>of delight already.... (Maybe we could work together on an entire
>alternate universe of C semantics...).
>
>	Hamish (feeling nostalgic)

Your hamish is my compiler.

Except I can't find that piece of paper, and it's been 22 hrs since
i've seen sleep.  Tough.  Hang on.

				--Blair
				  "a+b=c.  No.  Inadequate.  Yawn."

bill@twwells.com (T. William Wells) (10/30/89)

I've decided not to redirect this article to alt.flame, since Mr.
Giles apparently doesn't understand the purpose of doing my so,
and so that we can continue to watch him make a fool of himself.
:-(

In article <14109@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
: > You see, if you knew beans about C optimizers, [...]
:
: And you do, I suppose?  Then you can explain why you think C is
: faster than other languages in spite of the fact that it is inherently
: harder to optimize.

Don't put words in my mouth. As Doug has already pointed out, your
assertion, NOTE, YOURS NOT MINE (you goddamn hypocrite, yes, I've
seen your flames), is not always true.

As it happens, I *do* know a bit about C optimizers. And yes, by
and large, many, if not most, C optimizers are piss poor. But not
all of them. Some of them produce code that is very good. And for
certain applications, beat hell out of any Fortran compiler.

But the primary reason for the general relative efficiency of
Fortran and C compilers can be summarized in one word: history.

Fortran compilers have been around a lot longer than C compilers.

Fortran has also traditionally been used in applications where
any improvement in the optimizer translated into important gains
to the users. C has traditionally not been used in such. People
have generally had more of an incentive to work on Fortran
compiler optimizers than C's.

With the advent of graphics systems and the other munchers that
are becoming common, and with the push to make C as convenient
for numerical applications as Fortran is, I suspect that you'll
see this difference, where it exists, narrow and disappear.

:                      Once a program has been parsed and is represented
: by an abstract syntax tree (or some other intermediate representation)
: it is nearly impossible to tell what language the original source was
: in - except C which has more aliasing and potential dependencies than
: most other languages.  Also, C's character processing is less efficient
: as well.  In those respects that are important to compiling, C is
: nearly identical to most other imperative languages.  In those respects
: where it differs, it is harder to optimize.

A mishmash of true and false statements.

There are several things representable in C, things that are
important in the kinds of things C is often used for, that are not
easily representable in other languages, and so don't show up in
their syntax trees. Not only that, you are confusing the standard
methods of character (or did you mean string?) processing with
what is actually possible in the language.

When those attributes are important, C beats hell out of any
other language. When not, it depends. To those of us who
understand the language, the things that you mentioned that
happen to be true come as no surprise; we stopped debating them
ages ago. You certainly don't have anything new to tell us about
them.

: > You may have knowledge, but you are lacking in C wisdom.
:                                                  ^^^^^^^^
: Is that the peculiar mental condition which prevents you from discussing
: an issue without resorting to abuse?

What issues? Your whines about C? So far I've seen nothing from
you worthy of discussion.

Maybe if you actually learned something about the language as it
is actually used, and the techniques that competent programmers
have evolved to deal with C's known deficiencies, you might have
something to contribute. But so long as your comments are
directed to issues that have been resolved long ago, or are based
on theoretical grounds that have no bearing on practical use of
the language, or are directed to changing the language in ways
that will break significant amounts of existing code, you have
nothing to say that is worth my time to hear.

And argument by repetition will only draw flames.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.com

mcdonald@uxe.cso.uiuc.edu (10/30/89)

I am finally going to enter this flame war. This may seem a flame,
and indeed its is a bit. But I think mine is a reasonable position:

The most important aspect to a computer language is capability - 
if there are things that simply can't be done, or can only be done
with horrible kludges, then that language is either seriously flawed
or is intended for a specific subset of uses (even if it can be shown to
be Turing complete, and therefore essentially general in an algorithmic
sense.)  

The second is ease of use. Are there enough constructs in the language to
cover the intended uses (hopefully ALL uses for a general purpose language)?


The third is ease of optimizability. Are there constructs in the language
that make it hard to optimize? IF so, are there ways to help the compiler?
If there are problem areas, do the things that cause problems themselves have
sufficient utility that they overridde the optimization difficulties?

I personally use only assembler, Fortran (F77 here, as I withhold
judgement on F8x), and C. Lets consider them:

CApability: Well, assembler wins big here. It can do anything. Period.
Fortran lacks quite a bit: no pointers. No sturctures. No access to
all the size integers and reals that a machine may have (i.e. only
one integer size.) Function pointers only in a very limited sense.
And, did you ever try to do simple stream io in Fortran? 
C has a big list of capabilities. It lacks two features of Fortran
(conformant array passing and complex data type), but those can
easily be simulated, through minor kludges. Not really a big loss.
It also lacks Fortran's misfeature of the concept of a file "record",
though this can of course easily be simulated in C if one wishes.
The C language lacks only two things in its official ANSI form,
and, thank God, on many architectures they work anyway: converting
a data pointer to a code pointer and vice versa, and addressing
of absolute addresses (for device drivers, etc.)

Ease of use:   assembler - for most purposes, it isn't easy to use.
LAck of control constructs is the problrm here, as is lack of 
simple expression syntax. But, to be honest, expressions are not really
hard to do. Fortran is easy to use - so long as you are willing to
accept its lack of capabilities and not try to force them in. But, 
if you NEED a pointer, oh my, what a horrible mess. (Folks, believe me
on this one. Its really true. The key is to use it for just the type
programs it was intended for 'Formula Translation'. The lack of 
pointers helps a lot - there are no NULL flame wars. There is no
need for an "fdecl" program :-).  C is both hard and easy - it
is easy to express just about anything - look at the plethora of
operators and control constructs. But it is often very hard to get
declarations right - I could never do certain declarations without
either  a guru or "cdecl.exe". Try "pointer to array of pointers
to functions returning pointer to array of pointers to char and
taking as arguments a char, a void *, and a pointer of the same type
as I am trying to declare right now". "" I never saw a purple cow,
and never hope to see one. But I can tell you now, I'd rather see than 
be one."" Despite all the flame wars about it, I some how am just
not bother by NULL or (char *) 0 or whatever. It seems easy to me.

Ease of optimizability: One did not use to try to optimize assembler,
but with certain new RISC processors there appears to be a need to
optimize (schedule?) hand written assembler code. How hard it is,
I don't know. C loses here. Fortran is carefully constructed to
allow optimization. For example, arguments to functions (or subroutines,
I'll ignore the diference) are not allowed to have side effects - at all -
you can write code that does have that but - but - it is explicitly
disallowed by the Fortran language standard. And no pointers mean
no pointer aliasing. And you can't fake it with arrays - those can
not be used in that way. Its not allowed. The existance of aliases
restricts and/or hinders optimization of C. To do much at all
in the way of certain sorts of optimizations.
you need a really smart global data-flow analyzer.  "Const", "volatile"
and the concept of "noalias" can help only somewhat. Some compilers
(Microsoft C, for example) have a command line switch that for
all practical purposes calls the optimizer of Fortran. It seems
to work on my code - but, then again, to little gain. I don't consider
this lack of optimizability a big loss compared to the gains in 
ease of use and capability. OF course, there are lots of areas where C
can be optimized as well as anythings else.

C comes off looking pretty good.
But so do, in my opinion, Fortran and assembler. It's those silly
European invented languages that lose big. You know - the P's and
M's and the A's.
Doug McDonald