NOT Educating FORTRAN programmers to use C

[Jim Giles]

>From article <4459 at scolex.sco.COM>, by seanf at sco.COM (Sean Fagan):
> [...]                            However, let's pose this question to you:
> when was the last time you tried to write an OS in FORTRAN?  There are, of
> course, dozens written in C, but very few written in FORTRAN.  In that
> respect, C is a *much* more powerful language than FORTRAN.

Fine - since I never recommended Fortran as an OS implementation language.
However, I wouldn't recommend C either.  Of widely available languages, I
might pick something like Modula2.  Better languages than that exist, but
are not widely available.  Actually, so few people have need to write
operating systems that a language targeted just for that would be unlikely
to be a large scale success.

> [...]
>>> The standard allows str*() to be built-in.
>>Most ANSI standards allow additional features to be implemented in
>>a conforming processor.  I don't consider these extensions to be
>>an inherent part of the language.  
> 
> So, you don't consider PRINT, READ, WRITE, COS, SIN, etc., to be parts of
> FORTRAN?  [...]

Yes, I _do_ consider all the above features to be part of Fortran.  They
are all _required_ by the existing standard.  The _proposed_ ANSI C
standard on the other hand does not contain any such requirement for
'str*()'.  Therefore, it is not an inherent part of the language.  Many
Fortran implementations provide pointers - the standard allows such
extensions - but I don't consider pointers to be part of Fortran.  Just
because the language standard _allows_ a feature, doesn't make that
feature a part of the language.

> [...]
> However, C has at least one advantage, optimization-wise, over FORTRAN    
> [...]                                                                    
>             :  a C "module" does not consist of one routine per file.  This
> lets inline functions, global optimization and analysis, etc., be used,

It is true that in a Fortran environment, a 'file' is simply an external
storage object which may contain source for one or more procedures.  The
separate compilation rules of Fortran require the compiler to treat each
procedure separately - even if they do reside on the same file.  This allows
subsequent changes to the whole program to be performed by compiling only
those routines which are actually changed.

On the other hand, C uses files as part of the scoping mechanism.  It is
possible for the compiler to make use of its knowledge of other procedures
in the same file as the one current being compiled.  This would allow such
optimizations as you mention.  I'm not aware of any C compiler that I have
access to which actually performs such optimizations though.  This has
drawbacks anyway: in order to change one procedure you must recompile the
whole file.  What is worse, most C implementations will load all the
procedures from a given source file into the executable - even if some
are not actually on the call tree.

Other languages permit these types of optimizations as well (Pascal,
Modula2, etc.).  These languages too, however, suffer from the fact
that most implementations don't.

Fortran 90 (the new official title of the proposed standard) will address
this issue to a minor extent with 'INTERNAL' procedures.  I hope that
implementors will choose to optimize these (as well as their counterparts
in other languages - including C).

J. Giles