Re: Ada vs Fortran for scientific applications

[Dick Hendrickson <dick.hendrickson@att.net>]

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.

In general, the standard imposes restrictions on standard
conforming programs, not on the compiler.  This allows
compilers to extend the standard in "useful" ways.
Technically, a standard conforming program is not allowed
to use these extensions, but many do ;).  Most compilers
implement a command line option to do enhanced syntax
checking and report use of extensions.

Subscript bounds errors usually go unchecked and do
whatever they do.  They're really fun to debug because
adding a PRINT statement usually moves the effect to
some other part of the program.  This isn't Fortran's
greatest strength ;) .  It was a compromise between
safety and speed.

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.

Dick Hendrickson
> --
> Adrian
>