NOT Educating FORTRAN programmers to use C

[Jim Giles]

>From article <649 at chem.ucsd.EDU>, by tps at chem.ucsd.edu (Tom Stockfisch):
> I have never found a C typo as insidious.  If you type "+" for "=" it
> should be obvious when you proofread.

So should misspelled identifiers.  This kind of fatuous argument
is _barely worth responding to.  The old "forgotten */" problem with
C is often _very_ insidious.

>>Besides, most Fortran compilers
>>now have an IMPLICIT NONE statement
> 
> Given that it is Not Portable, I won't use it.

You mean like "pragms nolaias", which you mentioned as a solution for
a C problem?  You can't use non-portability as an objection if you
previously recommended a non-portable feature yourself.

Besides, I freely admit that Fortran _should_ have IMPLICIT NONE,
not just as an option, but as the default behaviour!  I don't defend
Fortran's use of implicit declarations.  I'm just pointing out
that C is not free of problems caused by typos just because is
requires all variables to be declared (as _you_ have implied).

>> [... remarks about Fortran trying to improve and C not ...]
> I think it is only fair to compare Fortran 8x to C++, not C.

C++ and Fortran 8x don't compare at all!  They start from different
languages and move in different directions.  Your idea of comparing
them further strengthens my main point: Fortran and C are different
languages with different strengths and weeknesses.  This is even MORE
true of Fortran 8x and C++.  They are aimed at different people using
different problem domains and the users whose problems fall in one
domain would be fools to use the other language.

> 
>>Poor Fortran programmers tend
>>to use GOTO too liberally and in inappropriate ways.  Poor C programmers
>>tend to do the same thing with pointers (the GOTO of data structuring).
> 
> "Address Of" considered harmful?

In fact, YES!  Dijkstra has written articles which might very well
have had that title.  C.A.R. Hoare has written that he doubted that
a language containing pointers could ever be truly called 'structured'.

> [...]
>>Besides, malloc isn't part of C - it's part of the support library.
> 
> It's officially part of standard C.  It has been de facto part of
> pre-standard C.

No.  It's part of the C standard - not part of standard C.  The
distinction is even made in the abstract of the proposed standard:
"Sections are included that detail the C language itself and the
contents of the C language execution library."

The distinction is important because a better way of providing
dynamic memory is to have an 'allocate' feature built into the
language itself which doesn't rely on user-visable pointers (and
their obnoxious tendency toward causing aliasing problems).

> 
>>If your Fortran has access to a LOC function (I have written LOC
>>functions for systems that _didn't_ have it), and if you can turn
>>off array bounds checking, then Fortran can even use malloc!
> 
> Highly unportable.

Agreed, but see below!

> [... argument that 'allocate' is better than malloc() ...]
> 
> I don't see why a noalias pragma can't fix that.

*****************************
> Highly unportable.
*****************************

I copied your own statement from above with my mouse.  What's sauce
for the goose ....

> [... argument that macros instead of real array refs are not good ...]

> Certainly on balance, C saves effort by being more expressive.

Even were I to agree that C is "Certainly on balance" more expressive,
this doesn't address the point that I made!  With respect to arrays
C is _NOT_ more expressive!

> [...]                                                          Adding
> a few extra characters in a declaration does not seem to terrible to me.
> It is more than offset by being able to say
> 	A( i+j, k-1, l/2 +7 ) +=	x
> instead of
> 	A( i+j, k-1, l/2 +7 ) = A( i+j, k-1, l/2 +7 ) +	x

C has existed for nearly 20 years.  The concept of 'expression
languages' has existed for nearly 30.  Yet, most language
designers don't choose to include such operators as above
(though they certainly are aware that they could).  Further,
implementors are constantly barraged with user requests for this
feature as local extensions - so users also seem pretty lukewarm
about these operators.

There have been studies to determine objectively whether such
assignments are helpful or not.  They have all been inconclusive.
It doesn't seem that any failing in the language can be said
to be "more than offset" by the presence of these assignments.
I, personally, regard the existence or absence of this assignment
syntax as completely irrelevant.

Studies have also been done to determine whether assignment should
be an expression-level operator or a statement-level one.  These
have shown that user productivity suffers if the operator is
an expression-level one.  Any possible advantage to having these
operators is probably "more than offset" by this failing.

> The =/== typo is probably a better criticism, although lint usually
> can catch it and people who work mostly with C tend not to do it.

And - people who work mostly with C tend not to use lint very much
either.  I think the two tendencies cancel.  I still can't imagine
why lint isn't built into the compiler.

> [...]
>>    C                         Fortran
>>
>>   *p                         MEM(P)
>>   *(p+i)                     MEM(P+I)
>>   p=malloc(amount)           P=MALLOC(AMOUNT)
>>   ...                        ...
> 
> What do you use for "[]"?

Syntactic sugar - irrelevant to the functionality.
> 
>>Of course, the Fortran compiler is required to do some things that
>>are automatic with C (like scaling the pointer arithmetic), but if
>>the previous example was considered an adequate replacemment for
>>Fortran arrays, then this should do nicely as a replacement for
>>C's pointers.
> 
> Not at all.  The C macro is perfectly portable, the fortran MALLOC
> is completely unportable.

Look again.  The Fortran would have to use non-standard features if
I used C's version of malloc().  But, the above doesn't imply that
I'm doing so.  If worst comes to worst, I _might_ have to statically
allocate the MEM array to a large size - but the above code is
completely portable!  This worst-case scenario would intail swapping
inefficiency (as you pointed out).  However, in 20+ years of programming,
I've _NEVER_ encountered a mainframe or mini which forced me to
statically allocate MEM.  Most actually make it easier by having
a compiler or loader directive like "dyn=MEM".

Meanwhile, if worst comes to worst, _YOU_ might get stuck with a
C compiler that doesn't support "pragma=noalias".  Which language
suffers from its respective failing most often (and what this
costs) I leave to your judgement.

So, I repeat: if your macros are considered an adequate replacement
for arrays, then this scheme should be considered adequate for
dynamic memory.  (I consider _NEITHER_ of these ideas adequate.
I don't support Fortran's lack of dynamic memory any more than
I support C's lack of genuine arrays.  But your claims about
the nature of these deficiencies are not valid.)

> [...] 
>>Actually, it makes a LOT more sense for a Fortran shop to wait for
>>Fortran 8x than it does for them to switch to C.
> 
> How many years will they have to wait for Fortran 8x?

That's not relevant to my remark!  For now, it makes more sense to wait
that it does to switch to C.  Later, it will make more sense to switch
to 8x than to C (or, still to wait, since 8x is supposed to be upward
compatible).

Besides, how many years will you have to wait for ANSI C.  Last I heard
it hasn't been approved yet either.

> How many more years after that before stable compilers exist on
> most machines?

Again, the same might be said about C.  And don't try to tell me that
C is already portable - I know better.  I just watched Cray porting
all the UNIX utilities to UNICOS!  Rumor is that it took more time
than estimated by a factor of 3!  (<- Not 3 factorial, by the way,
just 3. :-)  Apparently, moving from a 32-bit byte addressed machine
to a 64 bit word addressed machine was the main problem.  The C
code apparently hade _LOTS_ of assumptions along those lines.

By the way, the original estimate for porting the software was
based on Cray experience in porting Pascal and Fortran.  It appears
that, in this case, C was less portable than those other languages
by a lot (even if it wasn't a factor of 3 as per rumor, I know that
it was considerably behind schedule).

> [...]                        From what I've heard, Fortran 8x might be,
> like Ada, way too difficult to implement.

No. The only things that are really _new_ are the array syntax
(which is only difficult to implement on vector machines - which
have already received considerable study by the vendors of such
machines anyway), and the pointer facility (which is so bizarre
that no experience with other languages will be of help.  These
are both straightforward to implement, but efficient versions
may take a while.  The whole-array stuff should start out giving
about the same performance as existing equivalent loops - and
should improve from there.  The pointer stuff (as currently given)
will probably _always_ negatively impact performance in those
programs which use it.

Most of the other features are off-the-shelf copies of things done
in other languages (eg. derived types are just like Pascal records
or C structs - Fortran 8x is even simpler by not allowing variants).

> [... I oppose the current proposed Fortran standard ...]
> Is progress being made on revamping the proposal?

No.  The committee apparently believes the public review was sufficiently
positive this time to justify approval.  This, in spite of 1/3 opposed,
1/3 in favor, and 1/3 supporting the proposal in spirit but not liking
many of the new features.  The committee is viewing this as 2/3
approval - I would consider it 2/3 against.  For one thing, the
response has been much smaller this time.  The reason for not responding
that I heard the most was "they ignored my comments the first time,
they probably will again".

> Depends on the code.  I would probably leave most numerical Fortran
> programs alone.  A compiler written in Fortran I would probably
> translate to something else or rewrite from scratch.

I wouldn't rewrite a working compiler under any circumstances.  If
I were to code a compiler, I too wouldn't use Fortran.  I wouldn't
use C either (or C++, or Objective C, or ...).  My choice of existing
languages would be Modula2 or Objective Pascal.  My choice of experimental
languages would be Nemesis (of course - I am one of the designers :-).

> [...]
>>- preferably with a _much_
>>cleaner implementation than C++ provides.
> 
> Fortran8x will have a cleaner implementation than C++?

As I said before, C++ and Fortran 8x are languages which started in a
different place and _diverged_ from there.  Fortran 8x won't have
cleaner Object-Oriented stuff than C++ simply because it won't have ANY!
Objective Pascal is _much_ cleaner than C++.  Unfortunately, it's not
widely available yet.

J. Giles