Should I convert FORTRAN code to C?

[smryan at garth.UUCP]

In article <8184 at brl-smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <829 at garth.UUCP> smryan at garth.UUCP (Steven Ryan) writes:
>>C does not provide custom data types either. It permits new structures,
>>but those are not orthogonal to the primitive types: no new operators,
>>no new casts, (on some implementation) no new assignments, ...
>
>Wrong on all those counts.  C allows casting to any defined type and
>assignment of any structure type.  (If you feel like using an array,
>wrap a structure around it -- it's free.)

Just to clear up the terminology: in Algol68, the casts were introduced as
as contruct  "mode(value)" which told the compiler to coerce the mode of the
value into the indicated mode. A C cast confuses two distinct concepts with
one notation. For a "(primitive-type)value" cast, it coerces the value,
using widenning, narrowing, lengthenning, and a slew of other ill-defined
type conversions. For a "(complicated-type)value" cast, it overlays the
value's mode with a new mode--no coercion or any type of conversion is
applied. Hence a C cast is not orthogonal: it splits between a coercion
cast in simple cases and an overlay cast in complicated cases.

[Before correcting the above, I already know an A68 cast is
"formal-mode clause".]

>                                           New operators can be
>defined as macros or functions.  The one thing missing is overloading
>of existing built-in operator tokens such as "*"; C++ supports that
>but C does not.

Operators are conceptually distinct from function calls, both from the
programmers point of view, in how formulas are written, and from the
point of view of the compiler, in how the symbols and their operands are
identified. In a sufficiently high level language (not C), operators and
procedures are mapped into the same fundamental mechanism, but that
mechanism is neither a procedure nor an operator.

This discussion is why fortran should be converted to c, not c++.

>                 However, operator overloading is vastly overrated;
>most operations on extended data types do not map (unambiguously) onto
>the conventional arithmetic operations.

Eh? If you're talking about operator identification ambiguity that is a result
of a poor mode system. If you're talking about limited number of operators,
that is a result of poor operator syntax (it is possible to give operators a
generative syntax that permits arbritrarily many operators). If you're
trying to establish some kind mapping between operator meanings in any mode
and operator meanings for primitive modes, why?

To claim that C is an orthogonal and extensible language indicates a blithe
naiviety about these terms. Its data structuring is on the same level of
Pascal and just a little above Fortran. The only real difference is the
existence of a heterogenous array (struct in C, record in Pascal).

This shouldn't be considerred a criticism of C: lack of orthogonality has
permitted many convenient notations; lack of extensibility permits a simpler
language and compiler.