Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: My widget is more portable than yours (was Fortan versus C)
Message-ID: <4089@lanl.gov>
Date: 23 Sep 88 20:25:12 GMT
References: <1040@amelia.nas.nasa.gov>
Organization: Los Alamos National Laboratory
Lines: 47

From article <1040@amelia.nas.nasa.gov>, by fouts@lemming.nas.nasa.gov.nas.nasa.gov (Marty Fouts):
> [... example of non-porting C ...]
> This is an argument by anecdote. [...]

Yes, it's argument by anecdote.  That is, it's exactly the sort of
argument that's always used by C enthusiasts against Fortran.  If
it's invalid for me to use such arguments, then it's also invalid
for C supporters.

> It seems they were doing something like
>       COMMON /BLOCK1/ A(10000), I(1000)
>       COMMON /BLOCK2/ B(10000)
>       DO 10 I = 1, 30000
>         A(I) = 0.0
>    10 CONTINUE
> They were very upset when CDC wouldn't "fix" the problem.)

This argument is invalid because the above is non-standard (not only
that, the use of I in the do loop is illegal since I is declared to 
be an array).  Any non-standard Fortran shouldn't be expected to port
without _some_ degree of rewriting.  The point about C is that THERE
IS NO STANDARD.  So, any example of non-portable C code I show you
will demonstrate _my_ point in a perfectly valid manner.  When a
C standard becomes available, _then_ you can point to some mistake
in my C examples - not until.  

One problem still remains with C, however.  The proposed standard still
contains some deliberately ambiguous forms.  So, even after the standard
exists, there will be non-portable standard conforming code.  The Fortran
committee seeks to avoid ambiguity - as a result, standard conforming
Fortran code usually _does_ port.  If it doesn't, it's _usually_ a
compiler or library bug.  Only very rarely does an ambiguous Fortran
construct turn up - and when it does, there is usually a tacit agreement
among users and implementors - an ambiguous feature is, for all practical
purposes, a non-standard one.

When THERE IS a C standard, C will be more portable.  When the C standard
starts to outlaw ambiguous features, C will be even as portable as Fortran
(maybe).  In the meantime, the Fortran standards committee is busy adding
(I hope) most of the features that C users complain are missing.  Fortran 77
will remain more portable that C throughout this change.  Fortran 8x will
also be portable, but only to those places which support the new standard.
This latter problem faces C users as well - the new C standard will not be
universally available right from the start.

J. Giles
Los Alamos