From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 10 Dec 92 16:04:23 GMT
From: noc.near.net!inmet!spock!stt@uunet.uu.net  (Tucker Taft)
Subject: Re: How badly will C bias in the POSIX standards groups hurt Ada bindi
ngs?
Message-ID: <1992Dec10.160423.18972@inmet.camb.inmet.com>
List-Id: <comp.lang.ada>

I just wanted to reiterate a point that might have
been buried in Jim Lonjer's excellent response.

"Thick" means self-contained, whereas "Thin" means
defined in terms of the semantics specified in a 
language-independent standard (LIS).  

"Thin" does *not* imply a direct, C-like interface (e.g.
use of status parameters rather than exceptions, no private
types, etc.).

So really the whole thick vs. thin issue comes down to
timeliness/availability of an LIS binding (which is a *big* issue),
and convenience for the reader of the standard (you need two
documents instead of one, and good cross-reference skills).
The convenience issue can be overcome somewhat by creation of
an unofficial "combination" (thick) document, which enterprising 
book authors will hopefully produce in a timely fashion.

Thick vs. thin has *no* inherent effect on the abstractness or Ada-ness
of the binding.

Here is the relevant part from Jim's response ...

In article <1992Dec10.121345.4095@gvl.unisys.com> 
  lonjers@prc.unisys.com (Jim Lonjers) writes:

[lots of good stuff]


> . . .
>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'').

S. Tucker Taft     stt@inmet.com
Intermetrics, Inc.
Cambridge, MA  02138