Fortran 8x & X3J3 - some comments 
Author Message
 Fortran 8x & X3J3 - some comments

I got some time today and read X3J3's responses to my public comments,
and sent in a short objection to their responses.  I've summarized two
of my objections below.

Also, I got a letter from CBEMA today.  CBEMA states that my comments
for the second public review arrived there on Nov. 27 and are therefore
late and unofficial.  Since I sent it by Express Mail on Nov. 22 I
called the Post Office.  They said they tried to deliver it on Nov. 24
(the deadline), but couldn't.  So I called CBEMA.  It turns out they
were closed Thurs., Nov. 23 and Friday, Nov. 24 for Thanksgiving.
So the real deadline was Nov. 22!

Default Precision for Constants:

I suggested, as have others, the only simple way to fix conversion
problems is to extend IMPLICIT to cover constants.  No direct answer
from X3J3 other than they think KIND is sufficient for all uses.
I think its too cumbersome.  Most people won't use it for new programs,
and there will be a continuing problem with conversions.
An extension to IMPLICIT is what is needed.  This is especially
true now that the optional additional precision feature of DATA
statements has been deleted from the standard.  This means DEC
fortran users who rely on additional precision, i.e. those
that rely on DATA D1/ 0.123 / being equivalent to DATA D1/ 0.123D0 /
are now going to have to put D0 in each DATA statement in all there
programs.  Extend IMPLICIT so all they need to do is change or add
one line.  This also applies to all Fortrans which try to be DEC
compatible, e.g. Sun and Apollo, but not to IBM or VAX BSD f77, which
never used the optional additional precision.

Array Constructor Type & Type Params:

In the previous draft, the type of an array constructor was declared to
be the type of the first element.  Thus:

x = (/ 0, 0.5, 0.75, 1.0 /)

was equivalent to

x = (/ 0, 0, 0, 0, 1 /)

This is ridiculous.  I asked that the elements be converted to the {*filter*}
type as in a mixed mode expression.  Instead X3J3 has changed it to
require all elements to have the same type and type parameters.
In others words, the array constructor above is now non-standard.
However, people are still going to type constants this way and to
demand vendors to accept them.  Hopefully vendors will all do the
same thing with this.  Why didn't X3J3 choose a reasonaable meaning?

        - Jerry Berkman, U.C. Berkeley, (415)642-4804,



Wed, 19 May 1993 03:41:00 GMT  
 
 [ 1 post ] 

 Relevant Pages 

1. fortran 8x | ANSI fortran standards committee X3J3

2. FORTRAN 8x Public Comment Summary

3. A letter on FORTRAN-8x: comments? (long)

4. fortran 8x and fortran-77

5. FORTRAN-SC, FORTRAN 8x, AUGMENT I or AUGMENT II

6. Meeting of X3J3 - ANSI Fortran Standards Committee

7. Why have FORTRAN 8x at all?

8. Fortran 8X

9. Fortran 8x Information sought

10. fortran 8X grammar needed

11. Info on Fortran 8x

12. Books on Fortran 8X|90|Extended

 

 
Powered by phpBB® Forum Software