Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!wugate!uunet!mcsun!cernvax!achille
From: achille@cernvax.UUCP (achille petrilli)
Newsgroups: comp.lang.fortran
Subject: Re: Two Fortran Standards
Message-ID: <1073@cernvax.UUCP>
Date: 31 Aug 89 21:46:03 GMT
Reply-To: achille@cernvax.UUCP (achille petrilli)
Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland
Lines: 89
References:


Presley Smith writes in response to my article:
>
>1.  FORTRAN 77 permitted a processor to supply more precision derived
>    from a real constant than can be contained in a real datum when the 
>    constant is used to initialize a DOUBLE PRECISION data object in a 
>    DATA statement.  This standard does not permit a processor this 
>    option. 
Here I believe there is really nothing to complain about:
F77 "permitted" a processor to do something one way or the other. It was
not something you could RELY upon. Whoever has taken advantage of that
must be aware of inherent nonportability, even if we stick to F77.

>2.  If a named variable initialized in a DATA statement, and does not
>    have the SAVE attribute specified, FORTRAN 77 leaves its SAVE
>    attribute processor dependent.  This standard specifies that this
>    named variable has the SAVE attribute.
Here again is the same as point 1. I don't see how you can be portable
in F77 and RELY on DATA initialized variables to be SAVEd (or not), as this
is processor dependent. Being F8x more strict can lead to a change, true,
but after all, if one wants a variable to be SAVEd in this case, to be
portable, s/he would have to explicitly put it in a SAVE stmt.

>3.  FORTRAN 77 requires that the number of values required by the 
>    input list must be less than or equal to the number of values in 
>    the record during formatted input.  This standard specifies that    
>    the input record is logically padded with blanks if there are 
>    not enought values in the input list unless the PAD = NO option
>    is specified in an appropriate OPEN statement.
I cannot fully judge here, never fell into this trap. But if F77
"required" the input list to be less than or equal to the number of 
values in the record, it seems to me that not obeying to this rule
can produce, at the best, processor dependent results and at worst
some run-time error. Again the same as point 1 or 2.
And any way there is a way to go back to the previous behaviour.
I could say many things (all bad) about OPEN stmt in F77. It is probably
the stmt that always needs some change when porting a program, just having
to add PAD=NO is just part of routine maintenance. It would have been
much better if F77 had taken a more radical approach to OPEN.
F8x is now out to fix these problems, don't blame it for past errors.

>4.  This standard has more instrinsic functions than did FORTRAN 77
>    and adds a few intrinsic subroutines.  Therefore, a standard-
>    conforming FORTRAN 77 program may have a different interpretation
>    under this standard if it invokes a procedure having the same
>    name as one of the new standard intrinsic procedures, unless
>    that procedure is specified in an EXTERNAL statement as 
>    recommended for nonintrinsic functions in the appendix to the 
>    FORTRAN 77 standard. 
This could be a problem, but I see no solution to it, other than not
introducing any new intrinsic until year 2099. Many F77 implementations
introduce more intrinsic than the std prescribes, so what about 'em ?
This way we would have to stop any progress.
C is undergoing a standardization process as well.
New library functions have appeared, they too could clash with existing
names in existing programs, trigraphs have been introduced
in ANSI C, existing programs could behave differently, etc.
Any std is going to break something, especially in the previously
undefined or processor dependent areas. The problem is to minimize
those areas. F8x seems to be quite good in this respect as there are very
few things that have been broken intentionally.

I wrote:
>>Let get pragmatic, what should I rewrite under f8x ? do loops, ifs,
>>I/O statements ? what ?

Presley wrote:
>That's up to you.  do loops... do you want to use array notation for
>an example?  If you don't want to use new features, then don't change
>your code. 

What I meant was: do I HAVE to rewrite something otherwise it'll perform
differently ? The answer seems to be 'No, you don't have to if you don't
need new features'. That's enuff for me.
In this respect F77 broke badly F66 with the story of zero-trip loops
vs. one-trip loops. Also it gave us a very difficult transition from
Hollerith characters to the new character type. Life IS difficult
sometimes.

Presley writes:
>I believe that those that want 8x should have 8x.  And those that don't
>want it should not have it forced on them.  Seems like a simple enough 
>concept to me.  
For what I've seen up to now, if you don't want F8x, just stick to F77 stmts
in F8x. I don't see any reason to have 2 stds.
I have now some clearer ideas (for the time being :-).

Achille Petrilli
Cray and PWS Operations