Path: utzoo!attcan!utgpu!watmath!att!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!uwm.edu!mailrus!uflorida!novavax!hcx1!bill From: bill@ssd.harris.com (Bill Leonard) Newsgroups: comp.lang.fortran Subject: Re: Two Fortran Standards Message-ID: Date: 20 Sep 89 13:42:49 GMT References: : <1073@cernvax.UUCP> <608@mbph.UUCP> Sender: news@hcx1.UUCP Organization: Harris Computer Systems Division Lines: 53 In-reply-to: hybl@mbph.UUCP's message of 12 Sep 89 11:42:25 GMT > I believe that the group of "implementor extensions" should be > empty! If there are to be extensions, they should be Official > sanctioned extensions that you and others on the X3J3 committee > have reviewed. Sections 1.3.2(4) and 1.4 as contained in the > X3.9-1978 document are antithetical to the purpose described in > section 1.1. I take it that you are opposed, then, to extensions even if they are implemented by several vendors? I'll take a big leap and assume that your reason is because code which uses those extensions is not portable among the entire set of FORTRAN processors. Am I right? Then I think you must also be opposed to the FORTRAN/8x standard, because of the CHARACTER KIND= facility. Why? Because there is no requirement in F8x on what KINDs of CHARACTER a processor must provide. I suspect that vendors who do business in China and Japan, for example, will implement KINDs for the Oriental character sets; vendors who don't do business there probably won't bother. Hence, code written using Kanji would not be universally portable. This seems to me the same situation that arises with vendor extensions. In fact, I fail to see how your proposal for "Officially Sanctioned" extensions solves the problem either. There would still (I presume) not be any requirement that EVERY vendor implement those extensions. So how does this improve the situation? X3J3 has often refused to standardize extensions on the grounds that they are not required by a large body of users. I think that is a perfectly valid reason; in my opinion, it has not been applied often enough to F8x features. Nevertheless, it seems unreasonable to me that a user with a particular need (for instance, real-time computing) should be denied the language facilities he needs, simply because they would not be universally portable. Moreover, if the vendors waited for X3J3 to define the "Officially Sanctioned" extensions our customers need, we'd be out of business, and probably so would our customers. The ANSI process, indeed any design done by committee, is far too slow to react to the fast pace at which computer technology changes. I think your proposal turns the process upside-down. Vendor extensions should be the "proving ground" for language evolution. Only when a language feature has proven to be: 1) implementable; 2) widely used; and 3) portable to at least some degree, should it be standardized. I have no objection to standardizing extensions, once they have proven to be useful, for those extensions that are used by a small segment of users. But I don't think the standardization should come first; first one must prove that the perceived need does in fact exist, and that there are no serious impediments to implementation. -- Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.harris.com or hcx1!bill@uunet.uu.net