Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/Updates/9.mm

Text File | 1991-03-27 | 10KB | 275 lines

.\" Use -mm macros
.ds Rh 1003.9: FORTRAN Bindings
.ds Au Joseph J. King, Ph.D. <[e-mail]>
.ds Dt January 7-11, 1991
.ds Lo New Orleans, LA
.ds Ed Jeffrey S. Haemer <[e-mail]>
.ds Wd U\s-3SENIX\s0 Standards Watchdog Committee
.if '\*(Su'' \{\\
.ds Su the \*(Dt meeting in \*(Lo:
.\}
.if n \{\
.tm Subject: Standards Update, \*(Rh
.tm From: \*(Ed
.tm Reply-To: [e-mail]
.tm Organization: \*(Wd
.tm
.\}
.S 12
.TL
An Update on U\s-3NIX\s0\u\s-41\s0\d-Related Standards Activities
.FS 1.
UNIX\u\(rg\d is a Registered Trademark of UNIX System Laboratories
in the United States and other countries.
.FE
.nr :p 1
.sp
\*(Rh
.AF "\*(Ed, Report Editor"
.AU "\*(Wd"
.MT 4
.if n \{\
.nh
.na
.\}
.PF "'\*(DT Standards Update'     '\*(Rh'"
\*(DT
.sp
.P
\fB\*(Au\fP reports on \*(Su
.P
P\s-1OSIX\s0 is a set of portability standards
that will span a diverse set of architectures such as \s-1VMS\s0,
\s-1UNIX\s0, and \s-1OS/2\s0.
The \s-1FORTRAN\s0 binding to \s-1POSIX\s0 system services is nearing approval.
Here I'll discuss the current state,
including the relationship of language-independent \s-1POSIX\s0 standards
to the \s-1FORTRAN\s0 language binding,
and the possibility that the \s-1POSIX/FORTRAN\s0 binding will be rejected
by the International Standards Organization (\s-1ISO\s0).
.HU "Portable Operating System Interface: POSIX"
A \s-1POSIX\s0 standard is one of a group of standards being developed
by the Institute of Electric and Electronic Engineers (\s-1IEEE\s0),
in cooperation with the International Standards Organization (\s-1ISO\s0).
The primary mission of these standards is
to define a portable user and application environment.
The \s-1POSIX\s0 development effort is currently subdivided into
19 separate, numbered efforts
\(em 1003.0 (\s-1POSIX\s0 Guide) through 1003.18 (PEP).
Taken together,
these groups are forming operating-system standards in the areas that range
from networking to real-time.
Half a dozen additional groups,
also supervised by the \s-1IEEE\s0's Technical Committee on Operating Systems,
are creating related standards in areas like windowing toolkits.
While \s-1POSIX\s0 started with \s-1UNIX\s0 as a model,
\s-1POSIX\s0 standards are not limited to \s-1UNIX\s0.
For example, \s-1DIGITAL\s0 has announced a program
that will incorporate some of the \s-1POSIX\s0 standards into \s-1VMS\s0.
Once adopted and implemented,
\s-1POSIX\s0 standards will define a broad range of compatibility
both within the \s-1UNIX\s0 family of operating systems
and between other operating systems.
.HU "POSIX and FORTRAN"
What follows is the January 1991 report
on the progress of one of the \s-1POSIX\s0 working groups,
\s-1POSIX\s0.9.
P\s-1OSIX\s0.9 is responsible for
defining \s-1FORTRAN\s0 interfaces to the \s-1POSIX\s0 functionality
defined by the other working groups.
As a member of this committee
I need to keep track of the progress of other committees
to anticipate the next set of interfaces we will have to develop.
At the moment there is only one published \s-1POSIX\s0 standard,
which is referred to as \s-1POSIX\s0.1.\*F
.FS
First published as IEEE 1003.1-1988,
this standard has now been revised and updated,
and achieved international status as ISO/IEC 9945-1 : 1990(E).
.FE
P\s-1OSIX\s0.1 defines the functionality and C interface
to \s-1POSIX\s0 operating system services.
P\s-1OSIX\s0.9 is currently in public review
with a standard that defines \s-1FORTRAN\s0 interfaces
to the \s-1POSIX\s0.1 system services.
In addition to providing interfaces to system services
such as process creation and interrupt handling,
the draft also defines interfaces
that will improve \s-1FORTRAN\s0 application portability and interoperability.
For example,
the draft contains procedures for reading the command line arguments,
performing stream \s-1I/O\s0,
inheriting open files,
getting the time of day,
access to system constants,
access to system structures,
and
performing bit operations.
.HU "``Thick'' versus ``thin''"
The \s-1FORTRAN\s0 binding to \s-1POSIX\s0
is referred to as a ``thin'' binding.
That means that it defines the \s-1FORTRAN\s0 interfaces
to access the \s-1POSIX\s0 system services,
but does not define the functionality of those services.
Instead, the \s-1FORTRAN\s0 binding
references the \s-1POSIX\s0.1 standard for the functional definitions.
The Ada binding to \s-1POSIX\s0 is also nearing completion.
It is a ``thick'' binding,
in that it defines both the Ada interfaces and functionality.
.P
There are advantages and disadvantages to each approach.
Thick bindings are easier to read,
since all the information required is contained in one document.
Also by using the thick approach
it is easier to map the functionality into native-language constructs.
The Ada-bindings group has done just this
and has been praised for producing a binding that is very Ada-like
(as opposed to C-like).
.P
Thin bindings constitute a more conservative approach.
Since functionality is not defined in the thin binding,
there is no opportunity for errors or inconsistencies to be introduced.
Also, thin bindings are easier to adapt to changes in the base document.
For example, the \s-1FORTRAN\s0 binding currently references
the 1988 version of \s-1POSIX\s0.1.
Recently, however, \s-1POSIX\s0.1 has been updated (1990)
with several changes to functionality.
After careful analysis at the January meeting,
we determined that the \s-1FORTRAN\s0 binding
requires only one substantive change
to reference the 1990 standard as the base document.
.HU "ISO Requires Language Independence"
The International Standards Organization (\s-1ISO\s0)
at one time required all \s-1POSIX\s0 functionality
to be specified by language-independent standards.
These are standards that specify functionality
without specifying interfaces or syntax.
Thin binding standards are then produced for each language
to provide access to the functionality.
In the last year \s-1ISO\s0 has relaxed this restriction
to allow thick C bindings that define new functionality,
but has excluded all other language bindings
that do not reference a language-independent standard.
Even though the \s-1FORTRAN\s0 binding is a thin binding
it is based on the thick C binding
and not a language-independent specification
as \s-1ISO\s0 requires.
This is because there is no language-independent specification
and such a specification could be a year or more away.
.P
As a consequence, our working group will forward our draft
for \s-1IEEE\s0 and \s-1ANSI\s0 processing
when our work is complete.
We will also ask \s-1ISO\s0
if they wish to adopt the \s-1IEEE\s0 standard at that time.
This will give \s-1ISO\s0 another chance to say yes or no.
We hope that they will adopt our binding at that time.
If not, it may be several years
before a language-independent standard is developed
and we can produce a binding to it.
We feel that our binding
has usefulness in the \s-1FORTRAN\s0 community today,
so that an \s-1ANSI\s0 standard
even in the absence of an \s-1ISO\s0 standard
would be useful.
.HU "Other issues"
Other issues discussed at the January meeting included Fortran 90,
the ballot process,
and testing.
There was some discussion
of whether the \s-1POSIX\s0.9 draft standard
was Fortran-90-compatible.
Since the \s-1FORTRAN\s0 binding to \s-1POSIX\s0
only requires \s-1FORTRAN\s0 77 features
it was agreed that our binding should be compatible with Fortran 90 compilers.
We will look into this more carefully;
however, after reviewing the areas
in which Fortran 90 defines aspects for \s-1FORTRAN\s0 77
that were previously undefined,
I am confident that there are no conflicts
that would prevent our binding from executing properly
in a Fortran 90 environment.
.P
I presented a short summary of Fortran 90 features to the working group.
There was a discussion of which Fortran 90 features
might be used to increase the usability and portability
of the Fortran binding.
There was interest in using derived types
and user-defined operators
to create an unsigned data type for Fortran
\(em complete with the necessary mathematical operations.
There was also an opinion that we should limit the Fortran 90 features we use
to those already in existence in common practice
(e.g., structures and Include).
This would have the advantage that our Fortran 90 binding
would not require a full Fortran 90 implementation
and the disadvantage of not making the most of Fortran 90 features.
.P
When this is printed we will be processing public ballot comments.
The \s-1IEEE\s0 procedures for processing these comments
was explained to us at this meeting.
In order for our balloting to
be successful, the following criteria must be met;
.AL
.LI
we must receive back at least 75% of the ballots sent out and
.LI
75% of the yes-plus-no total must be yes.
.LE
Ballots received will be of one of three types,
yes, no, and abstain.
If there are any no votes
we are required to send out the objections
to all those in the ballot group.
They will then have the opportunity to change their vote.
We will make changes to the draft
and repeat this process until the necessary 75% is met
and there are no new objections.
.P
We discussed writing test assertions for our current draft.
These assertions are used by an implementor
to prove conformance to the standard.
It was agreed that, since the \s-1FORTRAN\s0 bindings is a thin standard,
our test assertions would be a thin document.
.P
.HU "Work to be done"
There is still much work to be done.
At our next meeting
we will be processing the public ballot.
We hope to a have a diverse range of opinions.
We are hoping that an active balloting group
will improve the quality of the standard.
In this way,
problems can be detected and fixed before they become part of the standard.
If all goes well, that could be as soon as December 1991.
.P
Our next meeting will be in Chicago in April
and you are welcome to attend.
After that we meet in Santa Clara in July.
[jsh -- Note that I changed this.  Am I right?]
Please contact either John, Loren, or me for details.
.nf
.sp
John McGrory (Chair)
Hewlett-Packard
19447 Pruneridge Ave
Cupertino, CA 95014
[e-mail]
[phone]
.sp
E.\ Loren Buhle, Jr., Ph.D.
University of Pennsylvania School of Medicine
Rm 440A
3401 Walnut Street
Philadelphia, PA 19104
[e-mail]
[phone]
.sp
Joseph J.\ King, Ph.D.
Genetics Computer Group
575 Science Drive, Suite B
Madison, WI 52711
[e-mail]
[phone]
.fi