comp.lang.ada
 help / color / mirror / Atom feed
From: gvls1!lonjers@louie.udel.edu  (Jim Lonjers)
Subject: Re: How badly will C bias in the POSIX standards groups hurt Ada bindi
Date: 10 Dec 92 12:13:45 GMT	[thread overview]
Message-ID: <1992Dec10.121345.4095@gvl.unisys.com> (raw)

In article <62711@mimsy.umd.edu> alex@cs.umd.edu (Alex Blakemore) writes:
>Dave Emery (hope I spelled it right :) gave a pretty depressing
>account of the international standards process for POSIX. I am particularly
>upset that the Ada9x binding to POSIX is going to be a thin layer binding.

That is, in fact the agreement that the Ada POSIX working group (IEEE WG
1003.5) has with ISO-IEC/SC22/WG15.

>Thick bindings are expensive, we cant afford to build them to everything, but
>the POSIX binding is an  example of when the incredible investment is worth it
>due to the large number of users.  Thin bindings are cheap and useful, but
>can cost users alot in mental model changes, unnecessary errors etc.
>This decision will help the few people who administer the standard and
>hurt the many more people that use the bindings.  Glad they have their
>priorities straight.

What you state is my personal (not the official working group) opinion on
the thick vs. thin issue.  However, there is no objective evidence, yet,
on whether the costs you mention will prove to exist.

I do, however, have my first anecdotal evidence.  The source is one of the
members of the POSIX working groups, one who has helped develop C bindings
and the Language indendent specification, but never worked on a non-C binding.
He recently had the experience of exploring the Ada binding and the FORTRAN
binding.  The FORTRAN binding is a thin binding to the C standard.  It is
the only thin binding in POSIX.

His conclusion:  thick bindings are far easier to read and use than the
thin bindings.

>Does this mean that the very nice Ada POSIX binding that just passed with
>greater than 90% approval will change radically in a few years?
>That people who invest in the current binding will be orphaned?
>That the new binding will be still born?

No, please do not suggest that those of us who built this standard have
wasted 4-5 years of our lives.  This binding will be useful for several
years, until a) Ada 9X is available on a wide range of platforms and
b) the economic demands on vendors encourage them to adopt an Ada 9X
binding rather than the current Ada `83 binding.

This subject:  migration of the POSIX standards efforts from Ada `83 to `9X
promises to be a very interesting discussion over the next couple of
months.

>Even if the current binding is a defacto success without the blessing of
>the ISO gods, the next version can still use some Ada9X
>features like child library units right? but probably cant use some
>Ada83 features like generics, exceptions :(

>How badly is this edict going to pervert the binding (other than to delay it)?

The plan is that it will not ``pervert'' the binding.  The terms ``thick''
and ``thin'' deserve some more precise terminology.  The terms that many of
us have adopted is ``fully specified'' vs. ``referential'' and primarily
refers to the form of the published document, rather than the technical
content of the binding.

Another aspect of this is the ``direct'' vs. ``abstract'' binding problem.
A direct binding is one which mimics the base document as closely as
possible, while an abstract binding exploits the host language as much as
possible while meeting the requirements of the base document.  (Define your
own level of abstraction for this one.)

There is very little support for direct bindings.  The current POSIX Ada
strategy -- being applied to the POSIX Ada Real Time standards effort
(P1003.20) is to develop a thin, abstract binding (again, no definition of
how abstract is ``abstract'').

This experiment will give us a better understanding of acceptance for the
``thin'' strategy as well as experience in the relative costs of standards
development.

>Is it possible to find some middle ground by using standard names etc
>but still provide an Ada friendly binding?
>Is it possible to have an Ada9X evolved version of the current thick
>binding sit on top (and be standardized in some way)?

>How much do you want to bet that the language independent specification
>(when it appears in several millenia) looks almost identical to the current
>C bindings?  That ISO wouldnt dream of having the C bindings change more than
>a couple of commas so that they dont upset the C POSIX users, but that they
>wont think twice of asking (nay telling) the Ada community to completely chang
e
>our bindings to conform to their views? (after all, they are not the ones who
>have to use the damn things)

I do not want to start any sort of flame war here.  I am only expressing my
personal opinion on this point:  Yes, the LIS does look a lot like C.
Several of us submitted ballots to assist the LIS group in migrating the
document into a more language neutral form.  There is a joint meeting
planned between the LIS developers and the Ada POSIX working group to
resolve the issues.  I trust an amicable arrangement can be worked out (I
have to be optimistic -- its my job).

>Is this decision irreversible? or work-aroundable?

Yes, the ``thin'' decision is being evaluted right now through the P1003.20
binding.  The working group will change its decision if the results of the
ballot indicate that it should.

Stay tuned to this channel for the formation of the formal balloting group
for this standard.  It should appear in either January or April.  See how
the binding works and submit your opinion.

Jim Lonjers
Chair, POSIX Ada Standards Working Group (IEEE WG 1003.5)

             reply	other threads:[~1992-12-10 12:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1992-12-10 12:13 Jim Lonjers [this message]
  -- strict thread matches above, loose matches on Subject: below --
1992-12-10 16:04 How badly will C bias in the POSIX standards groups hurt Ada bindi Tucker Taft
1992-12-11 12:39 fred j mccall 575-3539
1992-12-11 13:52 agate!spool.mu.edu!wupost!cs.utexas.edu!mars.tsd.arlut.utexas.edu!larry
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox