Standards Update, IEEE 1003.5: Ada-language Binding

[Jeffrey S. Haemer]

From: Jeffrey S. Haemer <jsh at usenix.org>



            An Update on UNIX* and C Standards Activities

                            September 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.5: Ada-language Binding Update

Ted Baker <tbaker at ajpo.sei.cmu.edu> reports on the July 10-14, 1989
meeting in San Jose, California:

The Ada-language binding for 1003.1 is progressing steadily, though
behind schedule.  The group agreed to try to prepare a document for
the October meeting in Brussels that is ready for mock ballot.  Those
at the meeting will decide whether the document has achieved this
goal.  If not, we will try again at the January meeting in New Orleans.

The slow progress is mainly due to the long time between meetings and
the limited workforce available to do the writing. The members, all
volunteers, must steal time for POSIX from their "real" (i.e.  paying)
jobs.  Attending quarterly meetings already puts most members near the
limit of time they can spare.

Most significant technical issues seem to be resolved; the remaining
controversies center on almost-religious issues, such as the exact
grouping of interface declarations into Ada packages, naming,
capitalization conventions, and where to strike the balance between
providing full functionality and idiot-proofing the interface.

Each chapter has been assigned to a person for review and editing,
based on decisions made at the San Jose meeting.  Quite a lot of
writing still needs to be done.  Chapter 7 ("Device- and Class-
Specific Functions" --i.e. terminal interfaces) is still empty, and
some others are still mostly just Ada code, with no discussion.  Most
of the rationale remains to be written.  Mitch Gart has agreed to
coordinate this, including a chapter on "meta-issues" -- design
decisions affecting the entire interface.  David Emery will combine
the chapters to produce the next draft.

Interaction with 1003.4 (Real-Time Extensions) has heated up, with
1003.4's consideration of support for multi-threaded processes.  Ada
language implementations must support multiple tasks (i.e. threads)

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

September 1989 Standards Update      IEEE 1003.5: Ada-language Binding


                                - 2 -

within a POSIX process, to comply with the Ada language standard.
Neither the 1003.1 standard nor the 1003.4 draft that just completed
mock balloting supports multithreaded processes, so the Ada
implementor is currently forced to hack out some sort of internal
concurrency scheme, with its own layer of dispatching, for each Ada
process.  This tends to run aground when one Ada task makes a blocking
system call, since the whole process is forced to wait.  Naturally,
Ada implementors and users would be pleased if the POSIX interface
provided for concurrency within a process.

The Ada group is very interested in the threads proposal, and most
members would like to see some support for threads in the 1003.4
standard that goes to formal ballot.  Some members are a little bit
concerned that those working on the proposal may not understand Ada
tasking well enough to insure that the proposed threads will be
adequate to implement Ada tasking semantics.  This has been very
frustrating for members of the Ada group, since the discussions of the
threads proposal were all in parallel with meetings of 1003.5.  The
best the Ada group was able to do was to keep one observer present (on
rotation) at the review of the threads proposal.  It is not clear
whether this was adequate.

[Editor's note: What's going on here, and in the second paragraph, is
that some groups are much larger than others.  1003.5 is among the
smallest.  The 1003.4 session I saw had about forty, overworked
attendees.  The 1003.5 sessions I saw had five to ten.

1003.5 could use a lot more participation from the Ada community.
Unfortunately, this may be a case of "once burned, twice shy".  For
years, there's been a lot of talk about "Ada environments", all of
which seem, from a UNIX perspective, like enormous, cumbersome
projects that might actually come into widespread use in, if not our
children's lifetimes, perhaps their children's.

Make no mistake about it: the Ada community is huge.  And easy
availability of machines with implemented, Ada-language bindings to
POSIX-conformant operating systems would be immensely useful to that
community.  The ability to buy a box, off-the-shelf, with a portable
environment for running Ada programs in the next couple of years,
would make Ada programmers' lives immensely easier and even be a big
aid in implementing the richer and more complex environments mentioned
in the previous paragraph.

Still, you can guess what the average, UNIX-naive, Ada programmer must
think: "Whoopie, another standard/environment.  I'll have to take a
look at it in a few years to see how it's coming along." If the IEEE
could make some non-vanishing fraction of the Ada community understand
that POSIX is on the verge of being here, now, dot 5 might get a lot
more help.

This seems to us (that's the editorial "we", folks) like a

September 1989 Standards Update      IEEE 1003.5: Ada-language Binding


                                - 3 -

quintessential marketing problem.  If 1003.5 could enlist the help of
1003.0 in this matter, they might be able to make some real headway
here.  ]

The 1003.5 group is also very interested in the progress of the
language-independent versions of the POSIX standard.  Much of the
labor of the Ada binding group has been devoted to separating the
essential semantics of the 1003.1 interface from the details of its
expression in the C language (for example, setjmp()/longjmp(), and
signal handlers).  This labor may be of use to those working on the
language-independent version of 1003.1, but the Ada group does wish
that new standards, such as 1003.4, would start out with a language-
independent document, rather than adding to the language-bias problem.

There was one change in the leadership of the 1003.5 working group.
Stowe Boyd, of Meridian, had been vice-chair but is no longer able to
spare time from his job to work on this project.  Steve Deller, of
Verdix, has agreed to replace him.  This is a very important job,
since the vice-chair of the 1003.5 group takes direct responsibility
for setting the technical agenda and running meetings.

September 1989 Standards Update      IEEE 1003.5: Ada-language Binding

Volume-Number: Volume 17, Number 41