Re: another way to shoot yourself in the foot?

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

Colin Paul Gloster wrote:
> On Wed, 9 Jul 2008, Richard Maine wrote:
> |------------------------------------------------------------------------|
> |"Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> wrote:                 |
> |[a very long post including quite a lot of quotations of me, among      |
> |others]                                                                 |
> |                                                                        |
> |I'm afraid that this post was too long and rambling for me to follow it.|
> |I could not detect any coherent message in it, other than perhaps a hint|
> |of randomly assembling quotes that sounded negative about Fortran (often|
> |out of context, at least for some of mine)."                            |
> |------------------------------------------------------------------------|
> 
> Dear Richard and everyone else,
> 
> I did not intentionally take quotes about Fortran out of
> context. If you can spare the time, then please help me to learn
> Fortran by explaining my misconceptions.
> 
> |------------------------------------------------------------------------|
> |" In addition to preferring                                             |
> |coherent organization and readability in my coding, I prefer the same in|
> |newsgroup postings.                                                     |
> |                                                                        |
> |If you have some actual message that you are hoping I might respond to, |
> |you'll have to state it a bit more coherently and concisely."           |
> |------------------------------------------------------------------------|
> 
> Please find below a summary of most of that post posed as yes-or-no
> questions. I have tried to rephrase
> /-----------------------------------------------------------------------/
> /"Gary Scott edited out all citations to newsgroup posts from circa 2007/
> /which do not promote Fortran. Perhaps posters to                       /
> /news:comp.lang.fortran would care to inform me as to whether or not    /
> /they are valid..."                                                     /
> /-----------------------------------------------------------------------/
> "a bit more coherently and concisely."
> 
> |------------------------------------------------------------------------|
> |" Decoding                                                              |
> |that tome doesn't seem worth the work. If the message is just a general |
> |language flame, which is perhaps the main flavor I hear, then you need  |
> |not bother, as I won't respond, coherent or not."                       |
> |------------------------------------------------------------------------|
> 
> I had looked at some Fortran newsgroup articles and webpages and code
> in 2007, but I have only started in a Fortran project this year. I
> have started to read a Fortran book for the first time this week. The
> Fortran project which I have joined so far involves replacing Fortran
> with C++. This had begun before I have joined. I do not approve of
> replacing Fortran with C++. However, if Ada is better than Fortran,
> then I approve of replacing Fortran and C++ with Ada. So, please
> rectify any misconceptions which I may have. (Later, if Fortran
> compilers produce much faster executables, then I may be motivated to
> use some Fortran even if I shall still believe then that Ada is a
> better language overall.)
> 
> I did point out in the long post that Ada is not perfect with respect
> to all of these flaws.
> 
> If answers differ with respect to different versions of Fortran
> (e.g. 77; 90; 95; 2003; 2008; and any others worth considering), then
> please elaborate accordingly...

There are really two answers to many of these questions.

The Fortran language prohibits many things, most of these
prohibitions are on the programmer.  Different compilers
check for different things; often there are compiler
switches to enable/disable particular checks.  For example,
run-time checks for out-of-bounds subscripts are often
expensive in time and disabled for production runs.

For the most part, the standard requires compiler checking
for syntax-like things and not run-time-value-related things.

> 
> Does Fortran have undefined behavior?
Sure, lots of it.  Many are for things that are purely
hardware related.  What should the standard say if the
heads fall off of a disk drive?  Others are a mixture
of hardware and software.  For example, integer overflow
is prohibited, but rarely detected by the hardware.  A
program which produces an integer overflow is non-standard;
but the standard does not specify a behavior.  Check the
list that Dan Nagle pointed to.  In general, there are
no size or complexity requirements that a compiler must
meet.

> 
> Does Fortran always automatically check if the INTERFACE actually
> corresponds to the code?
> 
Depends on the compiler, but in general NO.  I think all
compilers will detect an explicit assignment to a dummy
argument that has INTENT(IN) in the subroutine; I'm not sure
any will detect an assignment if the dummy is passed on
to another routine and that routine (illegally) assigns to
its argument.


> Does Fortran statically forbid out-of-bounds array accesses at
> compilation time?

It forbids them at all times.  The standard generally doesn't
distinguish between compile-time and run-time.  If a statement
is executed, the programmer must do the right thing.  In
     IF(A > B) C(I) = 1.0/D
if A is greater than B, I must be in bounds for the array
and D must be greater than or equal to zero (unless the
Fortran processor supports something like IEEE floating
point).

> 
> Does Fortran allow argument mismatch?
> 
NO.  Historically, with separate compilation, argument mismatches
were rarely detected by the compiler (some are not detectable
until run-time).  If you put things in modules, argument checking
is good at compile time.
> Are Fortran 90 modules compatible at the binary level on the same
> architecture?

Generally no.  Different compilers do things differently and the
standard does not specify module formats.  Nor does it specify
things like argument passing schemes, register save/restore,
stack management, etc.
> 
> Does Fortran have an exception mechanism?
> 
For some things.  I/O and memory management allow for error
detection and recovery by the program.  There is a set of
routines, etc., that allow Fortran to work with the IEEE
floating point exceptions.  There is no general user programmable
exception mechanism.

> Are "there are a number of things the Fortran standard leaves
> unspecified that it should pin down"?
> 
Sure, Maybe, No.  Take your pick.  Generally, I'd say no.
I think the balance between execution speed, compile time
checking, and user responsibility is pretty good.

> Does Fortran allow one to declare a type such as
> type
> The_Resolution_For_Nanoteslas_Supported_By_My_Analog_To_Digital_Converter
> is delta 1.0 / 2.0**5 range - 256.0 .. + 256.0 - 1 .0 / 2.0**5;
> (that is in Ada syntax, but I am not worried about the syntax: the
> feature is important, not how it is expressed)?

Yes, but not easily.  You can declare types.  If you do, then
you must provide functions that perform the operations and
optionally do assignments.  These routines can enforce value
checking.  There's no direct language support for ranges.

> 
> Does Fortran guarantee what happens during overflow for signed and
> unsigned integers?
There is no support for unsigned integers and no guarantee
about overflow for signed.  It's illegal to overflow, so there's
no need for the standard to specify what happens ;) .
> 
> Could Fortran 90 allocatables be left in an undefined state?
Yes.  That was fixed in F95.

> 
> Does Lahey's implementation of TR 15581 contain a bug which leaks
> memory?
> 
I believe all implementations of all languages contain bugs.  I
don't particularly know about Lahey's.  Historically, TR 15581
caused many compilers problems and it took them a while to get
it right.  It probably depends on the version of the compiler.

> Do the Fortran standards require detection of only trivial errors?
No.  The question is a little vague.

> 
> Is an optional garbage collector buggy?
> 
That's not really a compiler question.

> In principle FORALL should be good, but Fortran implementations
> thereof seem to be bad. Is this due to a flaw in the definition of
> Fortran itself?

Partly.  FORALL was essentially "cut and pasted" into Fortran
from HPF.  The intent was to allow compilers to easily
recognize things that could be spread out onto many processors.
Unfortunately, the restrictions on subscripts were a little
too loose and compilers have to perform a difficult analysis,
impossible at compile time for the interesting cases,
to avoid the need for temporary storage.  The Fortran 2008
DO CONCURRENT feature solves this problem, but there are no
compilers yet available ;) .
> 
> Does Fortran allow one to use an undefined variable?

In general NO.  Some intrinsics allow undefined arguments
and they can be passed on to a user subroutine, provided
the subroutine does the right thing.  The standard doesn't
require checking for undefined variables.  Given something
like
        DIMENSION  A(10000000000)
it's hard to imagine an efficient way to check for undefinedness.

If a value is required, the variable must be in a defined state,
but it's a programmer requirement.
> 
> Does Fortran allow a default value at the declaration of a variable?
Yes, however the way it is done often confuses people familiar
with other languages.

Dick Hendrickson
> 
> Yours sincerely,
> Colin Paul Gloster