nevin1@ihlpf.ATT.COM (00704a-Liber) (07/08/88)
[followups to comp.misc] In article <20520@beta.lanl.gov> jlg@beta.lanl.gov (Jim Giles) writes: >In article <5174@ihlpf.ATT.COM>, nevin1@ihlpf.ATT.COM (00704a-Liber) writes: >> Since when does 'x = x + 1' resemble anything besides an obviously false >> statement in mathematics?? Also, since many of us use C for tasks other >> than number crunching, does this mean that we should have NO desire for a >> programming language to resemble mathematics? Your reasoning is a little >> faulty here. >But not as faulty as yours. I maintain that the expression syntax >should be kept as close as possible to accepted mathematical conventions. >You seem to be maintaining that, because exact duplication is not possible, >the language designer shouldn't even try to be similar. If you are designing a language specifically for mathematics, then using an expression syntax consistent with mathematical conventions might be desired. However, most of what computers are used for is not for number crunching. What makes mathematical convention better than any other convention?? Another thing: people tend to think of the '+' operator (with respect to some computer languages) as being the same as the one commonly found in mathematics. These operators do not exhibit the same properties, however (in finite floating point arithmetic, addition is NOT associative. I wish I could remember who originally posted this fact). >If you would >read my entire statement (in which I said that both C _and_ Fortran were >far from perfect), you wouldn't be accusing me of claiming that assignment >is a mathematical syntax. Very little of what computers do correlates directly to mathematics. Mathematics is a declarative language, but computer languages are algorithmic. >> A function call may not necessarily be made (can you say 'inlining'). >I can not only SAY it, I can also notice that C doesn't do it (as I've >pointed out before). The C language definition (such as it is) doesn't >allow it. It has always been allowed (this is an implementation detail, not a language detail). >If the presence of an exponentiation operator can be considered as an >'error' in Fortran, then an inherently inefficient part of C can be >considered 'broken'. Who said that the exponentiation operator is an error in FORTRAN? But just because FORTRAN has it, that is no reason to believe that every other computer language should have it. If it doesn't fit in well with the language paradigm, then it shouldn't be kludged in. The inefficiency is due to implementation details; it is not inherent in the language. -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) You are in a little twisting maze of / / _ , __o ____ email paths, all different. / (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
ok@quintus.uucp (Richard A. O'Keefe) (07/09/88)
In article <5239@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704a-Liber,N.J.) writes: >>If the presence of an exponentiation operator can be considered as an >>'error' in Fortran, then an inherently inefficient part of C can be >>considered 'broken'. > >Who said that the exponentiation operator is an error in FORTRAN? But just >because FORTRAN has it, that is no reason to believe that every other computer >language should have it. If it doesn't fit in well with the language >paradigm, then it shouldn't be kludged in. Guilty. Although what I actually said was that the exponentiation operator may be MISLEADING, not that its presence is an error. What I had in mind is that, although there is no _real_ difference between operators and functions (even '+' may be a subroutine), operators _look_ cheaper, and my claim was that because pow() in C _looks_ dearer than ** in Fortran (even though they are essentially the same) this _might_ encourage people using C to stop and think a bit, and that when you stop and think you often find that ** is not appropriate after all.
jlg@beta.lanl.gov (Jim Giles) (07/12/88)
In article <5239@ihlpf.ATT.COM>, nevin1@ihlpf.ATT.COM (00704a-Liber) writes: > If you are designing a language specifically for mathematics, then using an > expression syntax consistent with mathematical conventions might be > desired. However, most of what computers are used for is not for number > crunching. What makes mathematical convention better than any other > convention?? The name of this news group is comp.lang.fortran.* Fortran IS a language specifically designed for mathematics (formula translation - remember?). However, all programming languages include features to support mathematical syntax. That portion of the language should indeed be close to normal mathematical convention. The thing that makes this convention better is the prior familiarity which most people already have with this notation. (* I know, someone cross-posted this discussion to comp.lang.c. I didn't do it. Besides, someone has now switched the whole discussion to comp.misc anyway, presumably to confuse anyone who is trying to follow it.) > Another thing: people tend to think of the '+' operator (with respect to > some computer languages) as being the same as the one commonly found in > mathematics. These operators do not exhibit the same properties, however > (in finite floating point arithmetic, addition is NOT associative. I wish > I could remember who originally posted this fact). It's an OLD piece of information. Should be the first thing that any new programmer learns. It is not the responsibility of the language designer to protect naive users from subtle problems like this (which they should learn anyway). Besides, all programming languages I've seen use the '+' operator anyway. Surely you aren't going to suggest changing THAT? > > [...] > Very little of what computers do correlates directly to mathematics. > Mathematics is a declarative language, but computer languages are > algorithmic. > This argument is flawed in the same way that the others were. If you do very little mathematics - so be it. But I bet you would still rather do that little bit in the traditional syntax (or, most people would). As I said before, if you're going to do something for which there is already a widely recognized syntactical convention - use the convention unless there is a really compelling reason against it. (By 'really compelling', I mean avoidance of syntactic ambiguity, constraints of the character set, or constraints of the hardware - things like that. 'Whim' is not compelling.) > [... Inline code expansion ...] > > It has always been allowed (this is an implementation detail, not a language > detail). C only allows inline expansion when the source of the called routine is available at compile time. Since C, like Fortran, is required to permit seperate compilation, it is required NOT to do inline expansion without the proper 'include' file present. Since C doesn't have the concept of 'intrinsic' functions, not even these can be expanded inline. This was the context of the original discussion - inline expansion of the 'pow' function. C can't do it (the rationale document for ANSI C admits this as a known problem with C by explicitly allowing it in the ANSI version). Now, if you're talking about letting the loader do code generation and expanding code inline that way - well any language can do that! Even Fortran. Since this discussion started as a C vs. Fortran on exponent operators issue - this mechanism still doesn't favor C. > > >If the presence of an exponentiation operator can be considered as an > >'error' in Fortran, then an inherently inefficient part of C can be > >considered 'broken'. > > Who said that the exponentiation operator is an error in FORTRAN? But just The originator of this argument did! He claimed it was confusing to naive users. I claimed (and still claim) that it's less confusing than a 'pow' function reference. > because FORTRAN has it, that is no reason to believe that every other computer > language should have it. If it doesn't fit in well with the language > paradigm, then it shouldn't be kludged in. I agree. But then, I don't think ANY programming language should contain 'kludged in' features. Most do (including both C and Fortran) because of historical development (backwards compatibility) and original design error. However, with respect to the exponentiation operator, including it in C would not constitute a kludge. It would introduce no new ambiguities (C has some old ones) and it would introduce no burden on those programs which don't use it. J. Giles Los Alamos
jlg@beta.lanl.gov (Jim Giles) (07/12/88)
In article <20666@beta.lanl.gov>, jlg@beta.lanl.gov (Jim Giles) writes: > [...] As I > said before, if you're going to do something for which there is already > a widely recognized syntactical convention - use the convention unless > there is a really compelling reason against it. (By 'really compelling', > I mean avoidance of syntactic ambiguity, constraints of the character > set, or constraints of the hardware - things like that. 'Whim' is not > compelling.) Another reason that isn't compelling is the one most C user have: "C doesn't do it, so it must not be good." This is similar to the other silly religious argument (oft heard, seldom true): "C does it this way, so it must be good." The point is that C (like all other programming languages) has some faults. I'm trying to identify some general guidelines for identifying faults and inadequacies in programming languages so that future designers can avoid them. One such guideline is given above. J. Giles Los Alamos