cik@l.cc.purdue.edu (Herman Rubin) (01/28/88)
In article <3057@zeus.TEK.COM>, rob@amadeus.TEK.COM (Dan Tilque) writes: > It seems to me that several of the recent changes (parens honored, for > example) to the proposed standard are for the benefit of numerical programmers > and/or vector processors. Most of the opposition seems to be coming from > systems programmers. The systems people generally say: these are unnecessary; > if you want them, use FORTRAN. The numerical programmers' answer is that C > produces much better code than FORTRAN. (Or, in the case of noalias, > neither C nor FORTRAN has it but it's still not needed for most systems > work.) > > My proposal is that we create a new language (perhaps called Cnum) in which > to put these type of features in. I find this far too restrictive. I find it the case that C produces better code than FORTRAN. However, all too often I find that I have to introduce assembler code into the C program. Unfortunately, all of the C compilers I have used do not allow the use of compiler-allocated locations in the assembler code, and also use the atrocious assembler syntax. There are things that a compiler can do, and C does many of them reasonably well, which should be made available to the programmer. A compiler uses temporaries, usually in registers, to store intermediate results. The programmer may have to break down steps in a procedure for the compiler to manage it; that results are of the type that the compiler uses for its intermediates should be usable by the programmer. There are machine instructions not understood by the language; we cannot have a language which understands all possible machine instructions. The programmer should be able to say that the syntax of an instruction is like that of another, in hardware only or in software only or both. Unfortunately, the use of overloaded operators is only available in compilers. It is not the case that FORTRAN or C is adequate for numerical mathematics. There are great weaknesses in both. There are portable operations, such as frexp, which should not have portable code in the primitives of a language. The code for &~ is not portable. Whether one should use ++ or index depends on the hardware. The programmer should be able to introduce macros in any notation, including infix, easily. We need a flexible language, and C may be the place to start. > oriented to numerical processing. It would be upwardly compatable (more > or less) from K&R C. It could also have an exponentiation operator and any > other features from FORTRAN which are deemed useful. Then, when any of these > kinds of features are proposed in the future, we can all say: "Use Cnum". > > It would probably be best to remove floats and doubles from C to further > emphasize the different uses of the two languages. > > Any comments? Has this been done or proposed before? > > > --- > Dan Tilque > > This is a borrowed account, so be sure to indicate that replies are for me > and not for Rob. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet