ahby@uinj.UI.ORG (Shane McCarron) (06/24/90)
From: ahby@uinj.UI.ORG (Shane McCarron) > From: Doug Gwyn <gwyn@smoke.brl.mil> > > Correct me if I'm mistaken, but I thought the specific task of > 1003.5 was to provide Ada-language bindings to 1003.1, not to > add functionality. Remember the history of POSIX.1. We have a standard which should have been specified in a language independent manner. If that had been done, a number of the functions that are in the standard would not be there, or would be in the C bindings section. They are convenience functions for C. Likewise, there will be convenience functions for other languages. Ada is particularly nasty, for all the obvious reasons. Someday there will be a language independent 1003.1 specification. It will detail the real functionality of the underlying system in such a way that it will be clear to people doing language bindings which features they must include. Until then, there will continue to be confusion on the subject. -- Shane P. McCarron ATT: +1 201 263-8400 x232 Project Manager UUCP: mccarron@uiunix.ui.org Volume-Number: Volume 20, Number 50
gwyn@smoke.brl.mil (Doug Gwyn) (06/27/90)
From: Doug Gwyn <gwyn@smoke.brl.mil> In article <738@longway.TIC.COM> From: ahby@uinj.UI.ORG (Shane McCarron) >Remember the history of POSIX.1. We have a standard which should have >been specified in a language independent manner. If that had been >done, a number of the functions that are in the standard would not be >there, or would be in the C bindings section. They are convenience >functions for C. Likewise, there will be convenience functions for >other languages. Ada is particularly nasty, for all the obvious >reasons. I DO remember the history of 1003.1; I was there! We most certainly did NOT set out to create a language-independent standard; C was specifically chosen for the obvious reason that it was the SOLE appropriate language for systems-level programming on UNIX, for a variety of reasons, including the fact that the UNIX kernel has a marked preference for being fed C data types. This "language binding" nonsense was foisted off on P1003 in an attempt to meet ISO guidelines. I think it must have been adopted by ISO as the result of Pascal types insisting that they never have to use any other language. Clearly, a BASIC, COBOL, or even LISP binding to 1003.1 would be ludicrous. I don't know how languages are selected for binding, but I do know what constitutes a UNIX system interface, and if a language can support one then that is what it should be given as a 1003.1 binding. Volume-Number: Volume 20, Number 51
buck@drax.gsfc.nasa.gov (Loren (Buck) Buchanan) (06/28/90)
From: buck@drax.gsfc.nasa.gov (Loren (Buck) Buchanan) In article <739@longway.TIC.COM> From: Doug Gwyn <gwyn@smoke.brl.mil> >I DO remember the history of 1003.1; I was there! We most certainly >did NOT set out to create a language-independent standard; C was >specifically chosen for the obvious reason that it was the SOLE >appropriate language for systems-level programming on UNIX, for a >variety of reasons, including the fact that the UNIX kernel has a >marked preference for being fed C data types. Sometimes you have to make painful changes, so that the future generations will not have to suffer with "historical artifacts". This is one place I think the changes should have been made (but of course I do not know all of the argumentation, compromises, etc. that passed before the committee came to an agreement. >This "language binding" nonsense was foisted off on P1003 in an >attempt to meet ISO guidelines. I think it must have been adopted >by ISO as the result of Pascal types insisting that they never have >to use any other language. I take exception to "nonsense was foisted". The reason for language bindings is so that various different languages can take advantage of the standard. Why should PASCALers, FORTRANers, etc. be coerced into giving up their favorite language. I regularly use three different langauges, and I expect that the operating environment I am working under will not impede my use of these languages. >Clearly, a BASIC, COBOL, or even LISP binding to 1003.1 would be >ludicrous. I don't know how languages are selected for binding, >but I do know what constitutes a UNIX system interface, and if a >language can support one then that is what it should be given as a >1003.1 binding. Why is it ludicrous, I think all of them should have bindings to POSIX, but don't ask me to do the work. If POSIX is to become truly universal, then it better support all of them and also RPG II/III, PL/I, Prolog, MUMPS, and any other general or special purpose language that is in common use. How a language is selected is two part, 1) is there a consensus of the committee that the work should be done, and 2) is there a fool ... eh ... er ... uh ... volunteer willing to do the work of creating and/or being the editor. I am currently working on the proposed image processing standard, and how acceptable do you think this standard would be if we ignored FORTRAN? B Cing U Buck -- Loren Buchanan | buck@drax.gsfc.nasa.gov | #include <std_disclaimer.h> CSC, 1100 West St. | ...!ames!dftsrv!drax!buck | typedef int by Laurel, MD 20707 | (301) 497-2531 | void where_prohibited(by law){} CD International lists over 40,000 pop music CDs, collect the whole set. Volume-Number: Volume 20, Number 57
gwyn@smoke.brl.mil (Doug Gwyn) (06/30/90)
From: Doug Gwyn <gwyn@smoke.brl.mil> In article <744@longway.TIC.COM> From: buck@drax.gsfc.nasa.gov (Loren Buchanan) >Why should PASCALers, FORTRANers, etc. be coerced into giving up >their favorite language. I regularly use three different langauges, >and I expect that the operating environment I am working under will >not impede my use of these languages. That's not what we're talking about. Pascal and Fortran can be fully implemented in a UNIX environment. You are not being asked to "give up" those languages. What I am saying is that you should not insist on using a language in an application domain for which it is ill suited. Fortran is not an appropriate choice for systems programming applications in a UNIX environment. While it is perhaps possible to devise a complete 1003.1 binding for Fortran (I suspect it wouldn't be possible for BASIC), there is no real need to do so. On the other end of the spectrum, Ada has its own notions of tasking that don't mesh well with UNIX's process model. Since the promulgators of Ada have insisted for years that Ada programs must not use extensions to the language, I suggest that holding them to their word would have been quite appropriate. Volume-Number: Volume 20, Number 71
jsh@usenix.org (Jeffrey S. Haemer) (09/18/90)
Submitted-by: jsh@usenix.org (Jeffrey S. Haemer)
An Update on UNIX*-Related Standards Activities
August, 1990
USENIX Standards Watchdog Committee
Jeffrey S. Haemer <jsh@usenix.org>, Report Editor
IEEE 1003.5: Ada bindings
Jayne Baker <cgb@d74sun.mitre.org> reports on the July 16-20 meeting
in Danvers, Massachusetts:
Introduction and Overview
P1003.5 completed the last touches on Draft 6 of the Ada Language
Binding, before sending it to ballot, and considered our options for
P1003.5 work beyond balloting. We also addressed the International
Standards Organization's (ISO's) refusal to accept and register our
draft and revised our balloting schedule.
Final Document Modifications
This meeting was our last chance to modify our document without a
formal IEEE ballot to justify that change. We spent a large portion
of the meeting editing Draft 5, chapter by chapter. Draft 6 will
ballot in less than two months, so document stability was guarded, but
we considered a few proposals for changes.
1. David Emery's Process Group ID as a Separate Type proposal
addresses the P1003.1 intention and underlying semantics with
respect to Process_Group_ID. Specifically, the proposal
recommends that Process_Group_ID be a separate type, or a
derived type at a minimum, rather than a part of Process_ID.
Dave believes that P1003.1 intended Process_ID and
Process_Group_ID to be treated as separate types. This
perception is supported by a few operations, such as
Wait_For_Process_Group, which suggest the two types are indeed
separate. Representing the two types separately would help
prevent confusing them. Making them separate would also allow
function overloading. For the most part, the group agreed, but
felt that the types really do behave more like derived types
than separate types.
There was some resistance to adopting this proposal because of
the number of changes it would require in sections 3 and 4
__________
* UNIXTM is a Registered Trademark of UNIX System Laboratories in
the United States and other countries.
August, 1990 Standards Update IEEE 1003.5: Ada bindings
- 2 -
(Process Primitives and Process Environment), but there was also
opposition to handing the problem off to the balloting group.
We finally decided to consult with the Language Independence
group.
2. A proposal submitted by Mars Gralia, of Applied Physics
Laboratory, Clarify Functional Option `FIFO', addressed a topic
presented in section 8 (Language-Specific Services for Ada),
This proposal was accepted because it introduced flexibility
that makes it easier for P1003.5 to support the P1003.4 work in
the future.
3. Mars also offered a Simplify and Unify proposal, which provoked
lengthy, somewhat heated discussion. Specifically, the section
8, Is_append, function returns yes/no, to support an existing
application, but there is a naming convention P1003.5 supports
that requires Is_Append to return a boolean; indeed, the append
function in section 6 (Input and Output Primitives) already
returns boolean.
Our priorities are
+ Consistency with the Ada language.
+ Consistency between the Ada and POSIX portions of the
document;
+ Consistency with existing implementations.
Unfortunately, some of these conflict with others in this case.
The good news is, we may not have to decide what to do: Ada
Interpretation (AI) 544 addresses this issue, However, we did
not know, and could not find out, the complete resolution of the
AI in Danvers. Moreover, Dave Emery and Hal Jespersen, who are
preparing the document for ballot, don't have time to make all
the changes Mars's proposal would require between now and ballot
circulation. Jim Lonjers suggested that Mars submit a negative
ballot on this issue, which would let the ballot-resolution
group construct a decision consistent with the AI during ballot
resolution.
Future Work
When Draft 6 enters the IEEE ballot process, the ballot resolution
group becomes responsible for ballot coordination and resolution, and
the working group is freed to submit new Program Authorization
Requests (PARs). IEEE policy only lets a group operate for six months
without a PAR, so we have to do our job quickly.
We listed possible new work areas, then ranked them based on our
effectiveness in the area, the work's importance, and the effort
August, 1990 Standards Update IEEE 1003.5: Ada bindings
- 3 -
required. Here is our list.
1. Test Assertions for P1003.5
A straw-man vote shows the test assertions work as the number
one issue, though we suspect neither our corporations nor our
individual bosses will be very interested in the work. However,
test assertions are a National Institute of Standards and
Technologies (NIST) requirement, which may increase corporate
interest levels. We do have total control over the test
assertions work, and have been directed by the SEC to address it
prior to our first round of IEEE ballot. To prevent a delay to
the first round of IEEE ballot, the SEC has allowed us to
include a ``plan'' for identifying and accomplishing the test
assertions portion of the document, rather than the actual test
assertions.
2. Shells & Utilities (Ada binding to P1003.2)
3. Language Independence (Helping P1003.1 -- create a language-
independent specification for 1003.1-1988, and 1003.1-1990.)
The Shell and Tools work and language independence ran close
seconds. The Shells & Tools work received a high ranking in the
straw-man vote because we feel that the work is do-able and that
our effectiveness in the area would be high; moreover, compared
to other areas (e.g., the P1003.4 work), the level of P1003.5
effort required would be low. Language-independence ranked high
as it is critical to both the current P1003.5 work (see ISO
Acceptance and Registration, below) and the POSIX effort as a
whole. The people working the language-independent issues are
asking for our input now. Moreover, without our input the
resulting language-independent work could adversely impact us,
and P1003.5 might not have the voting clout during balloting to
block anything particularly awful. Several members interested
in these issues are already holding Birds-of-a-Feather meetings
with the P1003.1 language-independent group.
4. Threads issues (Ada binding to P1003.4a) and Real-Time
Extensions (Ada binding to P1003.4)
This area generates the most interest among working group
members, several of whom have been working with P1003.4 for some
time. Ted Baker, former P1003.5 snitch, has written a document
on the subject, Real-time Extension for Portable Operating
System Ada Binding - Version 0.0 for the U.S. Army HQ CECOM
Center for Software Engineering, and provided us with copies for
review and consideration. Group consensus is that if we rush
into this area, we are likely to stumble over language-
independence issues, so we will work with the P1003.4 language-
independence small group until their specification is well
August, 1990 Standards Update IEEE 1003.5: Ada bindings
- 4 -
along, and then begin work on the Ada binding in parallel with
its completion.
ISO Acceptance and Registration
Jim Isaak, Technical Committee on Operating Systems (TCOS) Chairman,
reported to P1003.5 that ISO declined to accept and register P1003.5
at the recent Subcommittee 22 (SC22) Paris meeting. Their primary
reason was the lack of a language-independent specification for
P1003.1. How, they asked, can a language-dependent binding exist
without a base, language-independent specification? We had also
failed to use Working Group 11's procedure-calling mechanism to
generate our language bindings. (The WG11 approach produces a direct,
language-dependent binding to a language-independent specification.)
P1003.9, FORTRAN binding to P1003.1, suffered the same fate for the
same reasons.
For now, we will provide a copy of P1003.5 Draft 5 to SC22 for their
review and comments regarding potential registration problems in the
future. To address WG11 concerns, Jim Isaak, POSIX Strategy
Director -- note the different hat -- recommended we also forward a
copy of Draft 5 to WG11 for review. David Emery and I, both of MITRE,
will follow up with a white paper explaining, with examples, why a
one-to-one, direct mapping of the functionality described in the
language-independent specification to the language-dependent binding
is not always optimal, and that a complete (i.e., thick) language-
independent specification and a reference-type (i.e., thin) language-
dependent binding is neither practical nor possible for some
languages.
Finally, we will formally submit Draft 7 (or later) to SC22,
requesting they recommend it for ISO acceptance/registration as a
Committee Document (CD). (CD has replaced ``Draft Proposal'' or DP.)
The earliest this could happen is January 1991.
Why not Drafts 5 or 6? A new policy, intended to promote document
stability requires one IEEE ballot cycle before submitting a draft for
ISO registration.
IEEE Ballot Issues/Schedule
We met with Jim Isaak and Lorraine Kevra, the new TCOS Balloting
vice-chair, to discuss the IEEE balloting process and our balloting
schedule.
P1003.5 produced a schedule for achieving simultaneous IEEE and ISO
ballot at the April/Salt Lake City meeting (see my report from last
quarter), but because of the problems with ISO, described above, we
have revised this schedule.
August, 1990 Standards Update IEEE 1003.5: Ada bindings
- 5 -
Approximately 450 people joined the P1003.5 ballot group. Only 61 of
those people are POSIX participants; that is, only one-sixth of all
POSIX participants (from all working groups) signed up for our ballot
group! The other 390-odd participants are SIGAda members. We are
very pleased with this response.
Ballot-group formation closed on August 6. Confirmation to applicants
was originally scheduled for August 8. Because of the large number of
non-POSIX balloters, this date was pushed back to about August 17, but
anyone who signed up and has still not received confirmation should
contact Bob Pritchard at the IEEE Standards Office, 445 Hoes Lane,
Piscataway, NJ 08855, (908) 562-3811.
Now that ballot group formation has closed, the group cannot expand.
Only people who fail to respond to the initial ballot can be removed
(``abstain'' is not a non-response); ballot group members are not
required to respond to re-circulation ballots.
Bob Pritchard will mail Draft 6 to the P1003.5 ballot group on
September 10, 1990. The distribution takes a minimum of two weeks.
The ballot period officially begins on September 24, 1990, and closes
October 24, 1990. This allows the ballot group at least four weeks
for review. Being realistic, we imagine that not everyone will
complete their document review. To prevent the uneven coverage that
would result from 450 reviewers reading the document from front to
not-quite-back, our cover letter requests that reviewers begin their
reviews at different spots, using a scheme based on the first letter
of the reviewer's last name.
If people do not return their ballots by October 24, the IEEE office
may send a follow-up letter to the ballot group members requesting
that they return their ballots.
Steve Deller, of Verdix, will do all necessary coordination with
organizations listed on our PAR. Jim Lonjers, of Unisys, with
Lorraine Kevra's help, will coordinate ballot resolution, Each chapter
will have someone responsible for its resolution, but alternates for
each chapter are absolutely critical. Jim Isaak says that, based on
his experience, we should assume 20% of the people who do ballot
resolution will, for some reason, prove unable to complete their
portion of the task.
Jim Lonjers will provide the last ballot to the technical reviewers by
December 5, 1990. The ballot resolution group will meet at the Tri-
Ada meeting in early December to determine how close we are to
achieving the 75% minimum acceptance. At that same meeting they will
also coordinate ballot responses to objections which cover multiple
chapters and objections which produce conflicting responses. We
believe they will have resolved the last ballot by January 11, 1991,
and a re-circulation ballot is tentatively scheduled for the April
August, 1990 Standards Update IEEE 1003.5: Ada bindings
- 6 -
1991 POSIX meeting time frame.
In IEEE re-circulation ballot, two sets of material are returned to
the balloting group:
1. the changes made to the document (either a set of changes, or a
new document with change bars), and
2. the unresolved objections.
IEEE policy does not allow the balloters' names, companies, or company
locations to be returned with the unresolved objections packet; to
maintain anonymity, ballot comments are numbered, and individual
balloters notified of their own ballot comment numbers. (IEEE and
ANSI do maintain balloters' names, companies, and company locations to
detect corporate ballots, where and if they occur.) The balloting
group gets at least ten days to review the re-circulation ballot,
though they can be given more time if the size of the re-circulation
material and the document being balloted warrant it.
Miscellany
Eight Next Generation Computer Resources (NGCR) representatives gave
working-group participation quite a boost. Although NGCR people have
the bond of all being NGCR representatives, they are not employed by a
single employer, but are from all over the United States, and they
possess individual interests and strengths. In the past, our core
group has only been about a dozen people, so we are pleased by NGCR's
interest and participation, and eager to work with them.
In April 1990, David Emery went to Sweden, to meet with the Ada 9x
committee group dealing with secondary standards and setting
priorities of those standards. Secondary standards are those
standards not contained within the language itself (i.e., not in the
Ada Language Reference Manual). POSIX was a very high priority
secondary standard. The next Ada 9x committee meeting will be at the
SIGAda meeting in Los Angeles in August. Dave is heading a panel
presentation on the P1003.5 Binding at this meeting. The chapter
authors will also be a part of this panel.
At July POSIX meeting, P1003.5 expressed its special thanks to Dave
for his better-than-excellent job as our Technical Editor. He has
contributed significant time (much of it his own) and effort to the
P1003.5 work, and we appreciate it.
August, 1990 Standards Update IEEE 1003.5: Ada bindings
Volume-Number: Volume 21, Number 112rja7m@chaos.cs.Virginia.EDU (Ran Atkinson) (09/18/90)
Submitted-by: rja7m@chaos.cs.Virginia.EDU (Ran Atkinson) The comment in the snitch report about the committee "knowing" that 30 days being insufficient time to review the P1003.5 draft is distressing. Indeed I am one of the folks who is going to try to review the draft and 30 days is no where near enough time to do a proper job. The notion of starting at different places is NOT helpful because it is likely that my objections won't be evenly distributed across the document and because any I miss for lack of time can't be raised in a future ballot. The TCOS administration should REQUIRE that balloting groups be given sufficient time to review documents thoroughly. Otherwise we will end up with incompletely reviewed standards which we will then have to try to live with. This just serves to reinforce my view that the POSIX effort has changed from standardising existing practice with due deliberation to one to create as many standards documents as possible as quickly as possible without due regard for existing practice or internal consistency among the various documents that are under P1003. Standards are a good thing if done carefully. I'm concerned that the POSIX effort is moving too hastily to be truly useful to us users. Randall Atkinson randall@Virginia.EDU Volume-Number: Volume 21, Number 113