Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!mit-eddie!ll-xn!ames!hc!lanl!beta!jlg From: jlg@beta.lanl.gov (Jim Giles) Newsgroups: comp.misc Subject: Re: Expression syntax in programming languages. Keywords: C FORTRAN exponentiation Message-ID: <20666@beta.lanl.gov> Date: 11 Jul 88 19:52:24 GMT References: <3136@phoenix.Princeton.EDU> <19633@watmath.waterloo.edu> <5239@ihlpf.ATT.COM> Organization: Los Alamos National Laboratory Lines: 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