Path: utzoo!attcan!uunet!crdgw1!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpfcso!djm From: djm@hpfcso.HP.COM (Dan Magenheimer) Newsgroups: comp.lang.fortran Subject: FORTRAN POSIX bindings prepares to go to ballot Message-ID: <9080004@hpfcso.HP.COM> Date: 26 Jul 90 21:43:51 GMT Organization: Hewlett-Packard, Fort Collins, CO, USA Lines: 172 (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.GOV