Re: Ada vs Fortran for scientific applications

["Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk>]

On Wed, 24 May 2006 17:12:55 +0000, Dick Hendrickson wrote:

> 
> 
> Dr. Adrian Wrigley wrote:
>> On Wed, 24 May 2006 15:19:23 +0000, Dick Hendrickson wrote:
>> 
>> 
>>>
>>>robin wrote:
>>>
>>>>"Dick Hendrickson" <dick.hendrickson@att.net> wrote in message
>>>>news:PkHcg.90575$Fs1.7198@bgtnsc05-news.ops.worldnet.att.net...
>>>>
>>>>
>>>>>Ada's is surely better.  Knowing that a subscript has to be
>>>>>in range, because it's checked when a value is assigned to
>>>>>the subscript variable, has to be more efficient than what
>>>>>Fortran can do. In general, Fortran has to check the value
>>>>>of the subscripts on every array reference.
>>>>
>>>>
>>>>It can do this only if it is a compiler option.
>>>>It is not a feature the language.
>>>
>>>There's a ambiguous "it" in those sentences. ;)
>>>
>>>But, if "it" refers to Fortran, subscript bounds rules
>>>ARE a feature of the language.  You are NEVER allowed to
>>>execute an out-of-bounds array reference in a Fortran
>>>program.
>> 
>> ...
>> 
>> So what does the standard say must happen if you attempt
>> such an access?  Can a program fail unpredictably under
>> such (rather common!) circumstances - as routinely happens
>> in C and C++, sometimes at great cost?
> 
> The Fortran standard says nothing at all about what must
> happen for most run-time errors.  There is a requirement
> that a compiler be able to diagnose syntax-like errors at
> compile time.  There is also a requirement that some
> (unspecified) I/O errors and some memory management errors
> be checked for at run time.  The job will abort unless the
> program uses one of the error detection methods.  But for
> things like subscript bounds errors, or subroutine argument
> mismatches, the standard doesn't impose anything on the
> compiler.

...

> The other big problem with [old] Fortran programs was
> messing up the argument list in a procedure call.
> Separate compilation made this a lot easier to do.
> The Fortran 90 addition of MODULES essenially closes
> this hole.  Most procedure interfaces now can be explicit
> and the compiler must check for calling consistency.
> It's harder to shoot yourself in the foot now, but
> people can still lie to the compiler.

I think this is an area that Ada really shines.  The standard
requires numerous checks for consistency at both compile
time and runtime.  Versions of code that don't match properly
can't be linked together or can't be run together (as appropriate).
Using the language gives a feeling of integrity of coding,
with mistakes often being caught very early on.

Unfortunately, the language features for integrity cannot
be added to an existing language without breaking old
code.  This is because the integrity features are often a result
of prohibiting "dodgy" code, flawed syntax or misfeatures.
The history of the C family of languages illustrates this.
I'm not sure where modern Fortran sits in relation to
its forbears in terms of safety and security though.
It's noteworthy that Ada and Fortran are on convergent
paths (modules, user defined types, templates etc).

With array subscripts, an exception must be raised if the
bounds are exceeded.  The same with arithmetic operations.
(curiously, compiling Ada under gcc (GNAT), a compilation
switch is needed to be standards compliant - a mistake:().
The checks can be switched on and off in the source code
as desired.

One of the benefits of the compile- and run-time checking
is that refactoring code becomes much easier because the
compiler will usually tell you about what parts haven't
been fixed up yet.  Languages like C or Perl are at the
opposite end of the spectrum, I find.  From what I read here,
Fortran is somewhere in between.
--
Adrian