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