A Modest Proposal

[Herman Rubin]

In article <3057 at zeus.TEK.COM>, rob at 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 at l.cc.purdue.edu (ARPA or UUCP) or hrubin at purccvm.bitnet