Mathematical expression syntax (was: C vs. Fortran)
Jim Giles
jlg at beta.lanl.gov
Fri Jul 1 05:14:29 AEST 1988
In article <559 at lanl.gov>, dph at lanl.gov (David Huelsbeck) writes:
> Jim, I tend to think lisp looks more like mathematic syntax than
> Fortran does. A small subset of Fortran looks a lot like arithmetic
> but mathematics?
>
I don't have any mathematics texts that contain anything even remotely
resembling LISP at all. I have never seen any lisp construct in any
mathematics text. (I'm told that some, more esoteric, mathematics
fields have lamda calculus as a notational base - but I don't have
any of those.)
> I don't seem to remember seeing any DO loops in my mathematics texts.
Mathematics texts don't have flow control problems to deal with. As
a result, they never invented a standardized syntax for it. The parts
of Fortran which represent scalar mathematical expressions do a
creditable job of keeping to traditional mathematical syntax.
> Well, maybe in my numerical methods book but it also contained an
> arithmetic-if-statement in an example of "good code". Anybody who
> can defend the AIS should have no problem with x+=(p=foo(b)?++i:i--)
>
The converse is also true. Anyone who can defend x+=(p=foo(b)?++i:i--)
should have no trouble with the arithmetic IF. The arithmetic IF is
obsolete and is only maintained for backwards compatibility. I don't
know anyone who uses it for new code. The above C code is still
considered _good_ code?
> If you want something that really looks like mathematics, with the
> the for-all and the there-exists operators, and REAL subscripting and
> superscripting try MODCAP. (sigplan notices years ago)
>
I always thought that was called MADCAP. It was invented here at the
lab. The problem was not notational (real math syntax IS a good idea -
consider MACSYMA). The problem was typographical - new keyboards and
displays had to be built to use the language. For practical reasons,
programming languages are usually limited to syntaxes that flatten out
(or linearize) the math expressions. Subject to this constraint, the
closer the syntax resembles real math, the better.
Fortran certainly has a long way to go to meet this goal. C has further.
And, for any given language, there may be compelling reasons that some
types of mathematics can't be done. But, if a new data type or numerical
structure is added to a language, the synyax should be chosen to carefully
match existing notational conventions as closely as possible. If not,
really _good_ reasons should be required.
J. Giles
Los Alamos
More information about the Comp.lang.c
mailing list