jerry@violet.berkeley.edu ( Jerry Berkman ) (12/20/89)
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 dominant 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, jerry@violet.berkeley.edu