chris@mimsy.UUCP (Chris Torek) (09/15/88)
>In article <13547@mimsy.UUCP> I wrote: >>I do suggest, though, that no one use `i = i + 1' to increment. If you >>dislike `++', use `i += 1'. When you mean `add one to i', why not *say* >>it? In article <3568@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >'i = i + 1' _does_ say it!!! Indeed, in a certain sense---if one examines the semantics and considers the language definition, always, of course, keeping in mind the actions and situations and possibilities, and remembering all there is to contemplate upon, why, then, certainly---it does not say anything other than what it should say, which is to say, not to do anything other than to add one to i. Have I, perhance, managed to communicate with these words, these sentences, these paragraphs, the sense in which I mean to imply that `add one to i' and `take i, add one, and put it back' are, while they are certainly congruent in some aspects, and in ultimate true meaning identical, not at all the same? >Any compiler which generates different code for 'i = i + 1', 'i += 1', >and 'i++' is a certifiably _stupid_ compiler. Agreed. >Those three examples are semantically _identical_, their syntactic difference >is a textual convenience - at best. Also agreed. Convenience, however, makes all the difference. I, as a reader, would much rather see as an English description the phrase `add 1 to i' than `evaluate i, evaluate the integer constant 1, add the values together, and store the result in the location named by i'. Likewise, I would much rather read `i += 1' than `i = i + 1'. For such a trivial expression, the difference in convenience is minimal. But what about -- not in any particular language intensity(l1, II, l[I[1]]) += factors[Il[l1+I[II]]] Here the notational conveniece is quite significant. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
jlg@lanl.gov (Jim Giles) (09/16/88)
From article <13566@mimsy.UUCP>, by chris@mimsy.UUCP (Chris Torek): > Also agreed. Convenience, however, makes all the difference. I, as > a reader, would much rather see as an English description the phrase > `add 1 to i' than `evaluate i, evaluate the integer constant 1, add > the values together, and store the result in the location named by i'. My english description of 'i = i + 1' _is_ "add 1 to i". the difference between that and 'i += 1' is purely textual. It's easy to write a preprocessor to switch the later to the former. Such a preprocessor needn't have _any_ semantic knowledge of the target language. It need only look for '+=' and replace it with '= _X_' where _X_ is whatever token preceeds the '+='. In other words, as far as functionality goes, '+=" doesn't do a damn thing. J. Giles Los Alamos
warner@hydrovax.nmt.edu (M. Warner Losh) (09/16/88)
In article <3629@lanl.gov>, jlg@lanl.gov (Jim Giles) writes... >My english description of 'i = i + 1' _is_ "add 1 to i". the difference >between that and 'i += 1' is purely textual. It's easy to write a >preprocessor to switch the later to the former. Such a preprocessor >needn't have _any_ semantic knowledge of the target language. It need >only look for '+=' and replace it with '= _X_' where _X_ is whatever >token preceeds the '+='. In other words, as far as functionality >goes, '+=" doesn't do a damn thing. mild flame on As Chris has already pointed out, += doesn't do much for you in terms of functionality. It is more convient to use this notation. If you want to get really technical, then you should be programming in Turing machine logic, since it offers no more functionality than C or FORTRAN or any modern computer language. It has several probelms: 1) it is totally gross and unclear and 2) it takes several pages to do what you can do in FORTRAN or C in one line. That is why we do things in C or FORTAN, and not in Assmebler or Turning machine langues. The standard usage in 'C' (meaning, this is how most 'C' programmers program, not what *MUST* be done) is to use += or ++ . There was a time when += or ++ produced better code. That is why they were introduced to the language (I think, I haven't actually asked K&R). Since they are in wide spread use, must 'C' programmers know how to interpret these strange symbols. FORTRAN programmers will have some trouble here, since there is no EXACT analog in FORTRAN. This doesn't mean that they can't learn how to read them, it just means that it is hard at first. major flame on Can we now get back to talking about FORTRAN, and what the damn committee is doing to our FORTRAN? Ppppppplease? flame off C isn't FORTRAN. FORTRAN isn't C. >J. Giles >Los Alamos -- Warner Losh warner@hydrovax.nmt.edu ...!unmvax!nmtsun!warner%hydrovax "I don't know what language they will be programming in in the year 2000, but it will be called FORTRAN." -- Some one else... My spelling and views are my own. Only the vowels have been changed....
bgg@pyrps5 (Ben Golding - R+D Australia) (09/16/88)
In article <3629@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > the difference > between that and 'i += 1' is purely textual. It's easy to write a > preprocessor to switch the later to the former. Such a preprocessor > needn't have _any_ semantic knowledge of the target language. This is nonsense - it is not a "purely textual difference" if there are side effects. The "FORTRAN" statements: a(icomp(j)) += 1; and a(icomp(j)) = a(icomp(j)) + 1; are not purely textual substitutions if icomp is a function that changes the value of j. This distinction is particularly important in C where "i++" is commonly used and produces rather different results if the expression is evaluated twice. Ben Golding (bgg@yarra.oz.au) Pyramid Technology Corporation (Australia)
ags@h.cc.purdue.edu (Dave Seaman) (09/16/88)
In article <3629@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >My english description of 'i = i + 1' _is_ "add 1 to i". the difference >between that and 'i += 1' is purely textual. It's easy to write a >preprocessor to switch the later to the former. Such a preprocessor >needn't have _any_ semantic knowledge of the target language. It need >only look for '+=' and replace it with '= _X_' where _X_ is whatever >token preceeds the '+='. In other words, as far as functionality >goes, '+=" doesn't do a damn thing. If you apply your preprocessor to x[i*f(j)+k*g(l)] += y you get x[i*f(j)+k*g(l)] = x[i*f(j)+k*g(l)] + y which is not the same expression at all, becauses it causes the the subscript to be evaluated twice. -- Dave Seaman ags@j.cc.purdue.edu
mike@arizona.edu (Mike Coffin) (09/16/88)
From article <3629@lanl.gov>, by jlg@lanl.gov (Jim Giles): > In other words, as far as functionality goes, '+=" doesn't do a damn > thing. Well, actually it does. I admit, this is a minor quibble, but x[rand()] += 1; is not quite the same as x[rand()] = x[rand()] + 1; -- Mike Coffin mike@arizona.edu Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2,ihnp4}!arizona!mike Tucson, AZ 85721 (602)621-2858
chpf127@ut-emx.UUCP (J. Eaton) (09/16/88)
In article <3629@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > From article <13566@mimsy.UUCP>, by chris@mimsy.UUCP (Chris Torek): > > Also agreed. Convenience, however, makes all the difference. I, as > > a reader, would much rather see as an English description the phrase > > `add 1 to i' than `evaluate i, evaluate the integer constant 1, add > > the values together, and store the result in the location named by i'. Certainly, since the second description, while complete, is rather wordy. The first, while it is a convenient shorthand, isn't sufficient as a description [see below]. > My english description of 'i = i + 1' _is_ "add 1 to i". Hmmm. Mine is: `Huh? This can't be.', or: `No, I'm afraid that's false.' Unless I know more about the rules of the language it doesn't really mean a whole lot (neither does ++, or +=, or even :-). Your description "add 1 to i" only takes care of the right hand side, and does nothing to explain what the heck the left hand side and the equals sign are doing. I need to know more than "add 1 to i" to carry out all that's required by either C or Fortran; I need the second description given above by Chris. But that's wordy, so I'll use a shorthand, i++ or i+=1 in C, or even i=i+1 if I happen to be using Fortran. In any case, as long as we've agreed on the rules, and have a sufficiently clear and unambiguous definition of them, we should be all right. Is the real problem simply that someone in this discussion doesn't like the rules? J. Eaton Not really doing anything UT Austin Department of Chemical Engineering with chemicals.
jlg@lanl.gov (Jim Giles) (09/16/88)
From article <3976@h.cc.purdue.edu>, by ags@h.cc.purdue.edu (Dave Seaman): > If you apply your preprocessor to > x[i*f(j)+k*g(l)] += y > you get > x[i*f(j)+k*g(l)] = x[i*f(j)+k*g(l)] + y > which is not the same expression at all, becauses it causes the the subscript > to be evaluated twice. No, it doesn't cause the subscript to be evaluated twice. In Fortran functions are not allowed to have side effects. The compiler will therefore recognize the subscript expressions as common subexpressions and will evaluate only once. One guy had rand() in his example of subscript expressions - ever wonder why rand() isn't part of the Fortran standard? Ever wonder why most Fortran compilers warn against using rand() more than once in the same expression? This is why. Actually an expression like RAND(1)+RAND(2) _will_ call the random generator twice. Fortran assumes the lack of side effects, but a function applied to different arguments must be repeated for each different argument. Ever wonder why rand() takes an argument which it ignores? J. Giles Los Alamos
chris@mimsy.UUCP (Chris Torek) (09/16/88)
>In article <13566@mimsy.UUCP> I wrote a nice flowery description showing exactly why I say `i += 1' is superiour to `i = i + 1', and described it as follows: >>... I, as a reader, would much rather see as an English description the >>phrase `add 1 to i' than `evaluate i, evaluate the integer constant 1, >>add the values together, and store the result in the location named by i'. Likewise, I would rather see `i += 1' than `i = i + 1'. In article <3629@lanl.gov> jlg@lanl.gov (Jim Giles) answers: >My english description of 'i = i + 1' _is_ "add 1 to i". the difference >between that and 'i += 1' is purely textual. Very well. Let us remove the `**' operator from FORTRAN, replacing it with the `POWER' intrinsic. The difference is purely textual. >... In other words, as far as functionality goes, '+=" doesn't do a >damn thing. Actually, it does, although it would not in FORTRAN. In C, given int *pickone() { static int a, b; return (rand()&1 ? &a : &b); } the expressions *pickone() += 1; and *pickone() = *pickone() + 1; mean very different things. But this is irrelevant. The key is that the C language has op= operators, so you can expect anyone reading C code to be familiar with them. Since they more concisely express the intended result, you should use them. The FORTRAN languages do not have op= operators, and you cannot expect anyone reading FORTRAN code to be familiar with them. While they more concisely express the intended result, you should not use them lest you confuse the reader. Similarly, the FORTRAN language has the `**' operator. It more concisely expresses exponentiation than C's `pow()' function. It should be used ... in FORTRAN, and not in C. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
ags@h.cc.purdue.edu (Dave Seaman) (09/16/88)
In article <3659@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >No, it doesn't cause the subscript to be evaluated twice. In Fortran >functions are not allowed to have side effects. May I suggest that you read the standard before making such statements? At least one variety of side effect is explicitly permitted by the standard. I quote the last paragraph of Section 15.5.1, "Function Subprogram and FUNCTION Statement": An external function in a function subprogram may define one or more of its dummy arguments to return values in addition to the value of the function. So far I have not found any statements concerning other varieties of side effects, either for or against. I do note that section 15.5.3, "Function Subprogram Restrictions", fails to mention any restrictions on side effects. -- Dave Seaman ags@j.cc.purdue.edu
gl8f@bessel.acc.Virginia.EDU (Greg Lindahl) (09/17/88)
In article <3659@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > > [stuff deleted] > >No, it doesn't cause the subscript to be evaluated twice. In Fortran >functions are not allowed to have side effects. The compiler will >therefore recognize the subscript expressions as common subexpressions >and will evaluate only once. [...] > VAX/VMS fortran doesn't work this way, even with math library functions which are known to have no side-effects. if you write a = sin(x) b = sin(x) c = sin(x) it will call sin() 3 times. anyone have any idea why they would do this? Greg Lindahl internet: gl8f@virginia.edu U Va Dept. of Astronomy bitnet: gl8f@virginia.bitnet
jlg@lanl.gov (Jim Giles) (09/17/88)
From article <1123@nmtsun.nmt.edu>, by warner@hydrovax.nmt.edu (M. Warner Losh): > Can we now get back to talking about FORTRAN, and what the damn committee > is doing to our FORTRAN? Ppppppplease? > > flame off > > C isn't FORTRAN. FORTRAN isn't C. I agree. But a lot of the C supporters (and others) _seem_ to want to make Fortran more like C. Why discuss C in the comp.lang.fortran group at all except to compare features that _might_ be useful. I think there are a lot of things in C that might (with substantial modification) be useful for the Fortran committee to consider. I _KNOW_ that the committee is considering pointers. The point is that it is clearly undesireable for some of the (most touted) C features to _ever_ make it into Fortran. In light of this, it is perfectly valid to examine C features (good and bad) in the Fortran group. It is also valid, if you think a C feature is bad, to say so and give reasons why. Here are some features that _might_ be nice to see in Fortran: 1) Pointers - but _not_ the way C does them. 2) A preprocessor - but _not_ as an required part of the language. A supplimentary standard for a preprocessor could be devised which would complement the Fortran language without being a built-in part of it. 3) Exception handling - but, again, as a supplimentary standard. The supplimentary standard would describe a set of library routines which would provide the necessary functionality. And, again, without being a built-in part of the language itself. If you have questions about what constitutes a supplimentary standard, the Fortran 8x proposal (which has been effectively shot down) devoted appendix A to the subject. Supplimentary standards have the advantage that they are free to be designed with more than _one_ language in mind. The above list is in no way exhaustive. But the main idea is to keep an open (but not an empty) mind about features. Without doubt, C has a lot of very desireable properties. Fortran should take note of these, but without copying the undesireable ones (of which there are plenty). J. Giles Los Alamos
jlg@lanl.gov (Jim Giles) (09/17/88)
From article <13583@mimsy.UUCP>, by chris@mimsy.UUCP (Chris Torek): > Very well. Let us remove the `**' operator from FORTRAN, replacing it > with the `POWER' intrinsic. The difference is purely textual. My major objection to the pow() intrinsic (as you well know if you read the _long_ argument about it) was that C implements it inefficiently. Exponentiation should be an in-line function (if the compiler is capable). The C language design makes this impossible (pow() is an external, therefore it must be possible for the user to substitute his own version at load time, therefore it cannot be expanded in-line at compile time). The ANSI C standard will apparently address this. A secondary objection is that exponentiation is a mathematical operation for which mathematicians and others have always had (and still expect) a shorthand syntax. Assignment operator(s) have not this standing expectation from the user community - so shorthand variants really are just textual sugar for the few that _need_ such things. J. Giles
seanf@sco.COM (Sean Fagan) (09/17/88)
In article <3659@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <3976@h.cc.purdue.edu>, by ags@h.cc.purdue.edu (Dave Seaman): >> If you apply your preprocessor to >> x[i*f(j)+k*g(l)] += y >> you get >> x[i*f(j)+k*g(l)] = x[i*f(j)+k*g(l)] + y >> which is not the same expression at all, becauses it causes the the subscript >> to be evaluated twice. > [functions not allowed to return different values on the same input] [also not allowed to have side-effects] Wrong. They can. Also, with regards to side-effects, a FORTRAN function can modify a COMMON variable, or, happy happy, its argument. So what happens when j and l change between the first and second calls of f() and g(), respectively? Are you saying that the compiler can just optimize (incorrectly, I should add) the function calls into one function call? Which means that, in order to do what the programmer wants, he has to use temporary variables? Didn't I see an article a while ago saying that FORTRAN was nice because you didn't have to use temporary variables to get what you wanted evaluated correctly? >J. Giles >Los Alamos -- Sean Eric Fagan | "Joy is in the ears that hear, not in the mouth that speaks" seanf@sco.UUCP | -- Saltheart Foamfollower (S. R. Donaldson) (408) 458-1422 | Any opinions expressed are my own, not my employers'.
jlg@lanl.gov (Jim Giles) (09/17/88)
From article <3979@h.cc.purdue.edu>, by ags@h.cc.purdue.edu (Dave Seaman): > May I suggest that you read the standard before making such statements? > At least one variety of side effect is explicitly permitted by the > standard. I quote the last paragraph of Section 15.5.1, "Function > Subprogram and FUNCTION Statement": > > An external function in a function subprogram may define one or > more of its dummy arguments to return values in addition to the > value of the function. May I suggest that you read the standard before making such statements? I had forgotten the above (that is, in fact, the only side effect allowed explicitly). But you seem to have forgotten the last paragraph of Section 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 references. J. Giles Los Alamos
ags@h.cc.purdue.edu (Dave Seaman) (09/18/88)
In article <3701@lanl.gov> jlg@lanl.gov (Jim Giles) writes: [ After I quoted the standard to prove he was wrong about side effects] >May I suggest that you read the standard before making such statements? >I had forgotten the above (that is, in fact, the only side effect >allowed explicitly). But you seem to have forgotten the last paragraph >of Section 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 references. > Now, wait just a minute. I have not forgotten anything. I never said that there were NO situatations in which side effects were disallowed. I was careful to say that I had found ONE instance in which side effects are permitted by the standard. This is already enough to prove my point that side effects are not always forbidden. You, after all, were claiming right up until you read my response that there were NO situations in which side effects were allowed. You said that it was not possible to implement a random number generator in standard Fortran. You said that allowing side effects is "an extension to the standard." And now you are telling me that I am the one who needs to read the standard? Let me point out two things about the statement you quoted from the standard. If the intent was to rule out side effects altogether, then why is that first clause there? Why is the restriction so narrowly worded that it applies only when there are multiple function calls in a statement? And why does it only rule out one particular category of side effect (the ones that would affect the functions' returned values)? It does not even guarantee that it is safe to evaluate the subscript only once in my example which started this discussion. The function may increment a variable in COMMON each time it is called. This need not affect the value returned by the function, but it certainly can affect other parts of the program. Judging by your latest reply, you apparently still believe that all side effects other than the one I quoted are forbidden. I claim the standard says otherwise. I do not have the standard in front of me as I write this, but I can paraphrase some things that I read two days ago. My evidence: 1. The section on statement functions contains a restriction that is somewhat similar in spirit to the one you quoted: If a statement function calls an external function, the external function may not alter any of the statement function arguments. Again, the reason for the restriction is clear. Again, the restriction was worded as narrowly as possible. The clear implication is that whatever is not specifically prohibited in the standard is allowed (at least as far as side effects are concerned). More on this in a moment. 2. The section that spells out restrictions on external functions fails to restrict side effects in any way, as I previously noted. 3. I remember reading a statement to the effect that "whatever is allowed in external subroutines is also allowed in external functions, with the following two exceptions ...." I looked up the cited exceptions, and neither of them concerns side effects. Since side effects are permitted in subroutines, it looks very much as if they are permitted in functions as well. I will look up the paragraph number for this if you don't believe me, but you shouldn't have any trouble finding it yourself. It is obviously in the chapter that talks about external functions. In short, I claim that side effects are normally legal in Fortran functions, and I believe the burden of proof is on you to show otherwise. Isolated special cases do not count. It is the general rule that I am concerned with. -- Dave Seaman ags@j.cc.purdue.edu
peter@ficc.uu.net (Peter da Silva) (09/19/88)
In article <3697@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > Exponentiation should be an in-line function (if the compiler is capable). Agreed... > The C language design makes this impossible (pow() is an external, therefore > it must be possible for the user to substitute his own version at load time, > therefore it cannot be expanded in-line at compile time). This is not true. Just because something in 'C' has the form of a function does not mean it is forced to be a function: getchar() min()/max() on many machines feof() isprint() All of these are macros. Many compilers implement strcpy() and related functions inline just because this gives a speed advantage on certain types of problems (such as dhrystone :->). > A secondary objection is that > exponentiation is a mathematical operation for which mathematicians > and others have always had (and still expect) a shorthand syntax. This syntax is, however, not the one Fortran uses. The mathematical syntax for exponentiation is actually not displayable in ASCII text. -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" peter@ficc.uu.net
jlg@lanl.gov (Jim Giles) (09/20/88)
From article <1267@scolex>, by seanf@sco.COM (Sean Fagan): > [functions not allowed to return different values on the same input] > [also not allowed to have side-effects] > > Wrong. They can. Also, with regards to side-effects, a FORTRAN function Please read _all_ of section 6.6 of the Fortran 77 manual. There are numerous constraints on the side effects of functions contained therein. Admittedly, these are the _only_ constraints on side effects of Fortran functions, but they cover the case under present consideration _completely_. J. Giles Los Alamos
thompson@batcomputer.tn.cornell.edu (Steve Thompson) (09/21/88)
In article <561@hudson.acc.virginia.edu> gl8f@bessel.acc.Virginia.EDU (Greg Lindahl) writes:
VAX/VMS fortran doesn't work this way, even with math library functions
which are known to have no side-effects. if you write
a = sin(x)
b = sin(x)
c = sin(x)
it will call sin() 3 times. anyone have any idea why they would do this?
I couldn't believe this when I saw it, so I checked it on my VMS V4.7/
FORTRAN V4.8 system. Sin(x) does get called only ONCE, as you can
easily verify by looking at the machine code listing.