djm@hpfcso.HP.COM (Dan Magenheimer) (07/27/90)
(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. and members of the TCOS-SS
(no extra charge to join). 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. [Editor: Institutional
Representatives are exceptions to this rule. See IEEE 1003.1-1988,
p. 177 for a detailed explanation of the rules.]
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.
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. 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
As the committee prepares to go to ballot, it might be of value to
review some of the more sticky issues that the working group has
addressed. The formal, adopted charter of the committee is to provide
access to the POSIX-defined, standard operating system interface and
environment, directly from the FORTRAN language. There are two major
issues of scope that bear comment: ``Access to how much of POSIX?''
and ``Which FORTRAN?''
Some POSIX features are easily imagined as useful to a FORTRAN
application (e.g., chmod, exec, etc.); some are less easily imagined
(pick your favorite obscure system call). It was unclear where to
draw the line, so the committee took the attitude of ensuring access
to all features defined in 1003.1 (IEEE 1003.1-1988, or ISO/IEC 9945-
1:1990). It seemed clear that full functional access would be
provided by most vendors, so full standardization seemed called for.
Some diehard C language addicts continue to ask, ``Why have any
FORTRAN bindings?'' Although most vendors provide a method of calling
C functions from FORTRAN, they vary from vendor to vendor. Further,
any library of C routines provided by a vendor to map FORTRAN
constructs to the POSIX defined procedures is bound to differ among
vendors. The P1003.9 bindings are silent on implementation, so the
FORTRAN subprograms defined in the bindings could be implemented as
just such a library. The bindings just standardize the interface.
Keeping in mind the POSIX goal of application portability, only a
truly complete FORTRAN binding would provide portability of any
FORTRAN application.
A harder issue was, ``Which FORTRAN?'' Our choices were:
1. FORTRAN 77 [ANSI X3.9-1978, ISO 1539-1980 (E)],
2. a codification of common extensions/enhancements to FORTRAN 77,
or
3. the revised FORTRAN standard emerging from the ANSI X3J3
committee -- previously referred to as FORTRAN 8X but now
called Fortran 90. (The working group has been delighted to
have an officially appointed representative of X3J3 as an active
member.) [Editor: Note that Fortran 90 will finally let us type
the name of the language without using the caps-lock key. ``And
gain is gain, however small.'' -- Robert Browning]
We chose the first.
For FORTRAN 77 vs. Fortran 90, we were swayed by the fact that FORTRAN
77 is currently the only adopted standard. (Fortran 90 is scheduled
to be adopted as an ANSI standard after P1003.9 goes to ballot.)
Further, FORTRAN-77-based applications are expected to exist for some
years. Thus, the working group felt that FORTRAN-77-based bindings
would be of value to the user community. The working group expects to
develop a new set of bindings, based solely on Fortran 90, after
completion of the FORTRAN 77 bindings (and after the Fortran 90
standard is adopted). One result of this decision is a subprogram-
naming scheme that reflects the version of the language (e.g., CALL
F77MKDIR(...) ). This will ensure that there will be no name-space
conflict with similar-purpose subprograms in a future Fortran 90
binding.
An even harder issue, once we decided to base the bindings on FORTRAN
77, was whether to define the bindings as extensions and/or
enhancements to the language itself, or simply as a library of
callable FORTRAN subprograms. While the latter was finally chosen,
there was considerable argument for the former. 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. Fortran 90 specifies
uniqueness to 31 characters and all current FORTRAN 77 compilers
researched provide this extension. Further, since the list of P1003.9
subprogram names is finite, if necessary, a vendor could provide a
preprocessor to convert these names into unique strings of six
characters.
If the P1003.9 bindings had defined changes to the language itself,
then major missing constructs in the FORTRAN 77 language needed for
easy POSIX access (most notably, structures and pointers) could have
been provided by choosing either the emerging Fortran 90 constructs or
an existing vendor solution. At first the working group felt that
this might be required for some access features. However, as we
struggled with each issue, working papers and proposals were
introduced that resolved every one with callable FORTRAN subprograms
(though some might argue about elegance or ease of use). While we
mostly steered clear of ``ease-of-implementation'' arguments, since we
viewed the FORTRAN 77 bindings as an interim, we felt that vendors
would be quicker to implement a library of subprograms than
modifications to compilers.
A final, hard question of standard scope concerned whether to restrict
the standard to 1003.1, or expand it to general, FORTRAN-application
portability issues, both within and outside the POSIX arena. Both a
lack of resources and a desire to provide a timely bindings on the
heels of 1003.1 made us decide to limit the scope to 1003.1
functionality.
As other base standards are produced (e.g., 1003.2, 1003.4, etc.), we
expect to construct and ballot bindings for those standards. For
example, we have worked with P1003.2 in defining a standardized
command to invoke the FORTRAN compiler (after a number of iterations,
now named fort77) which is part of their current draft. Actual
P1003.9 bindings to 1003.2 might include definitions of additional
utilities of use to FORTRAN applications not mentioned in the base
1003.2 standard (e.g., f77split, f77lint, etc.).
Another argument against adding features was that many, if not most,
of the problems we saw in portability are solved by new constructs in
Fortran 90. Many of us felt that as a standards group we should only
provide a minimum set of features for ``perhaps-soon-to-be-obsolete''
FORTRAN 77, and thereby speed up the date for providing full bindings
to the new Fortran 90, which provides more features for application
portability.
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. Nevertheless, if you wish to discuss them before this
you can also directly contact the chair (John McGrory) or me (vice-
chair, Michael Hannah), or join the e-mail discussion group.
Addresses follow:
P1003.9 Chair
John McGrory
Hewlett Packard Co.
Division 2615
19046 Pruneridge Avenue
Cupertino, Ca 95014
mcgrory%hpda@HPLABS.HP.COM
P1003.9 ViceChair
Michael Hannah
Sandia National Labs
Albuquerque, NM 87185
mjhanna@SANDIA.GOV
Un-moderated mailing list:
posix-fortran@SANDIA.GOV
To join the list, send request to:
posix-fortran-request@SANDIA.GOVbam@bnlux0.bnl.gov (Bruce A. Martin) (08/01/90)
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.]
caywood@teb.larc.nasa.gov (John Caywood) (08/02/90)
In article <2035@bnlux0.bnl.gov> bam@bnlux0.bnl.gov (Bruce A. Martin) writes: >In article <9080004@hpfcso.HP.COM> djm@hpfcso.HP.COM (Dan Magenheimer) writes: >> >>Subcommittee (TCOS-SS), all members of the ballot group must be both > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>regular IEEE or Computer Society members. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >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! > >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, ...) > The original statement was just a bit incomplete. Objections from non-IEEE members must be resolved to the objector's satisfaction, just as if they came from a member; the difference is that if a non-member says Hey, this is great, it doesn't count toward (the official definition of) consensus. Consequently, your objections *DO* receive attention, whether or not you are an IEEE or CS member. You can also note that this policy makes it more difficult for a single organization or group to flood the balloting group with affirmatives in an attempt to force through an unpopular standard. It does *not* prevent a group from flooding the ballots with objections to block the adoption of an unpopular standard (a balloting diode? :-) Please note that these are merely observations -- I don't imply that there is no better way to ballot. John Caywood, Secty. POSIX.10