jlg@beta.lanl.gov (Jim Giles) (07/01/88)
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 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. > |The choice I'm talking about is whether to cause a function call (the > |most expensive of all the 'simple' operations). Doesn't matter what the > |subroutine library does, you've already made the expensive call. > > 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. The proposed ANSI C will, I am led to believe, address this issue. > > |Fine, C is fixing something that shouldn't have been broken to begin with. > > It was never broken (a little inefficient, but not broken). 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'. > > |Finally! Something we agree upon. But what does this have to do with > |the value of placing the operator into the syntax? Just because it's > |seldom used for large or non-constant arguments, doesn't mean it needs > |to be arcane or cryptic when it IS used. > > If all the arguments are constant, what do you need a run-time operator > for? The language used above was English. I will attempt to translate it for you. Example: I don't put cream in my coffee very often, but that doesn't mean that cream shouldn't be available. Example: I don't use large, non-constant, or non-integer exponents very often, but that doesn't mean it should be hard for me to do so if I wish. Nor should it be hard for me to use the small, constant, or integer exponents that I use more frequently. (What's a 'run-time operator'? All operators are source code objects.) Since I don't know what language you actually use, I can only hope that several similar English examples will be sufficient. J. Giles Los Alamos
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