Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!sharkey!bnlux0!bam From: bam@bnlux0.bnl.gov (Bruce A. Martin) Newsgroups: comp.lang.fortran Subject: Re: FORTRAN POSIX bindings prepares to go to ballot Summary: Privately developed "standards" vs. public review. Keywords: IEEE Ballot Groups, Public Review & Comment Message-ID: <2035@bnlux0.bnl.gov> Date: 1 Aug 90 16:16:11 GMT References: <9080004@hpfcso.HP.COM> Organization: Grumman Synchrotron Light Source Program @ BNL Lines: 182 cc: posix-fortran-request@SANDIA.GOV In article <9080004@hpfcso.HP.COM> djm@hpfcso.HP.COM (Dan Magenheimer) writes: >(I'm posting this for Michael Hannah, the vice-chair of the POSIX FORTRAN >bindings group. See below for address for responses. Discussion in this >newsgroup is also welcome.) > >FORTRAN bindings committee prepares to go to ballot > >The FORTRAN bindings committee is preparing the official call for a >ballot group. Because the POSIX work is all done under the auspices >of the IEEE Technical Committee on Operating Systems Standards >Subcommittee (TCOS-SS), all members of the ballot group must be both ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >regular IEEE or Computer Society members. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This membership requirement (which I have protested for many years) is highly objectionable in a standards process, and should be the subject of scorn & ridicule [perhaps in some more appropriate group]. I am not an Electrical Engineer and have no desire to support *their* professional society. (The issue is not only financial: I do not wish to lend my name to the political opinions IEEE occasionally espouses.) By contrast, EE's have been welcome to comment on publicly-developed software standards, and their comments are treated equally with those of others. This is true, regardless of whether they pay dues to ACM! (And regardless of whether they agree with ACM stands on Scharansky or SDI.) Isn't it about time somebody objected to IEEE's practice of developing their own "standard", with a "members-only" ballot groups, and then later presenting it as a take-it-or-leave-it candidate for ANSI standardization, thus turning the ANSI "Public Review & Comment" process into a mere plebiscite. This also makes a mockery of the "consensus process" which ANSI claims to require of its accredited standards bodies. Non-IEEE comments are rendered moot because the so-called technical commitee generally ends all technical deliberations long before the ANSI *public* comment period begins! >... Non-members may submit informative >ballots, but such ballots cannot count towards the required response >percentage (75%), or percentage of affirmative responses (also 75%) >required for passage of the standard. This stands in sharp contrast to the practice of X3 (and others) of developing true consensus standards via an open process which does not give special status to dues-paying members of a particular organization. (No, you don't have to be a member of CBEMA to receive attention to your public comment, to submit proposals, or even to join a Technical Committee and vote on letter ballots.) >For more information, the appropriate membership forms, and >instructions for returning the forms to the proper IEEE offices, >contact the committee chair, John McGrory, at the address listed at >the end of this article. This information/sign-up packet will be >available by the end of June, but you may contact the chair as soon as >you want your name added to the distribution list. This IEEE practice reminds me more and more of the TV scams urging people to call a 900 number (at $2 a pop) in order to voice their opinions. I resent IEEE's use of the standards process to drum up business almost as much as I resent their exclusion of the general public from the development process. >:-( >The formal sign-up period is expected to be August 15 through October >19, 1990. The ballot period is expected to last from November 9, 1990 >through January 4, 1991. We are especially eager to attract a large, >representative balloting group, and encourage interested individuals ^^^^^^^^^^^^^^ >to sign up. Your wishes are no doubt sincere, but the organization which sponsors and controls the process is and has been blatantly hypocritical in its policies and procedures. >...While the views represented on the P1003.9 working group >have been appropriate and varied, the number of active members has >been small (typically, around a dozen). > >Some history > >... Thanks. I enjoyed this history, and do appreciate your well-written and informative summary. Also, I am glad that IEEE permits you to inform us outsiders about some of the things that have been going on inside your members-only group. ;-) Unfortunately, if previous practice holds, the ANSI "Public Review & Comment Period" (in which commenters are not discriminated against on the basis of professional society affiliation) will be held at a time when the technical committee has already completed its technical work and is no longer willing or able to consider technical, philo- sophical, or editorial opinions of the previously excluded public. __________________________ End of tirade. __________________________ >... >(Fortran 90 is scheduled >to be adopted as an ANSI standard after P1003.9 goes to ballot.) Merely a quibble: Fortran 90 is scheduled to become an ISO standard quite soon, replacing ISO Fortran 77. It is not at all clear whether or not it will ever become an ANSI standard, and X3 has decided to "freeze" the ANSI Fortran 77 standard in a manner that does not require upward compatibility. (i.e. Conforming 77 compilers may be allowed to offer Fortran 90 syntax with different semantics. But that's a whole 'nother flame war, and I digress.) >... One result of this decision is a subprogram- >naming scheme that reflects the version of the language (e.g., CALL >F77MKDIR(...) ). I think this is downright silly. Since Fortran 90 is a superset of Fortran 77, any 77-conforming interfaces could have exactly the same form in 90. Sure, you might want to add some goodies later for 90 only, but there is no reason to create two complete sets of names! >... This will ensure that there will be no name-space >conflict with similar-purpose subprograms in a future Fortran 90 >binding. To ensure that, you would only need new names for those (probably few) bindings which must be incompatible for Fortran 90. Even these could be made upward-compatible thru the use of Fortran 90 features such as generic interfaces, optional parameters, and keyword arguments, with the procedure name remaining unchanged. (Consider, for example, the Fortran 90 extensions to AINT, CMPLX, or INDEX -- it was not necessary to create another intrinsic name to add "KIND" or "BACK". >... In fact, one >extension to FORTRAN 77 was considered minimally essential. The >current document requires the language to differentiate external names >unique to 31 characters, even though the FORTRAN 77 standard limits >them to six. The extension seems harmless. *I* don't mind this a bit, but you should expect howls of protest from certain vendors. [By the way, do you allow vendors? Must their company join IEEE or are they merely restricted in who they may send?] >Fortran 90 specifies uniqueness to 31 characters Actually, 90 specifies a *maximum* of 31 characters (and full uniqueness). >and all current FORTRAN 77 compilers researched provide this extension. You obviously researched a different set of compilers than those I've found!! >... if necessary, a vendor could provide a >preprocessor to convert these names into unique strings of six characters. This assumes that all programs treat your new names as "reserved words". >... we felt that vendors >would be quicker to implement a library of subprograms than >modifications to compilers. I agree. (I also hope you asked the vendors.) >... >How to get involved > >If you have strong feelings about these issues, the most effective >avenue to express them at this point is to join the balloting group >being formed. ^^^^^^^^^^^^^^^^^^^^^^^^ Ah. But this requires joining IEEE, paying dues, and agreeing with (or acquiescing to) its stated positions and opinions. { GO TO TIRADE } -/s/- BAM Bruce A. Martin [Address given for identification only.] Grumman Space Systems [Every conceivable disclaimer applies!!] c/o National Synchrotron Light Source [Opinions are mine only, & will change,] Bldg. 725C, Brookhaven National Lab. [without notice, whenever appropriate!!] Upton, NY 11973 (516) 282-3712 *New Address -- effective 16 July 1990* my email addresses remain: bam@bnlux0.bnl.gov or bam@gdstech.grumman.com [DISCLAIMER: The statements made herein do not necessarily reflect those of any other individual, group, organization, corporation, or government agency. My work on X3J3 does not in any way represent official policies or positions of my past or present employers nor those of any other sponsor or affiliate.]