thick? thin? binding

thick? thin? binding

[Immanuel Scholz]

Hi,

I read through 1 and a half Ada book and still doesnt catch what "thick" or 
"thin" binding mean... I know "flat" binding from C or "name mangling" from 
C++. It this related to this?

Immanuel Scholz

Re: thick? thin? binding

[tmoran]

> I read through 1 and a half Ada book and still doesnt catch what "thick" or
> "thin" binding mean
It's an informal term, originally referring to the thickness of the docs
for the binding.  For instance, a binding to Windows that just has the
pragma Import specifications for the various function calls, and let's you
go to some book on C calls in Windows for information, would be thin.  A
somewhat thicker binding would use Ada types and type checking, perhaps
raise an exception on error instead of returning a code, etc.  It would
need some documentation of its own, but not too much.  A thick binding
would look like Ada, not C, perhaps use Ada tasking and OO instead of the
message loop and case statement, use controlled types to help ensure
things get properly destroyed with all the right Windows calls, etc.  An
extremely thick binding would hide even the fact you were running on
Windows rather than Unix.  See the "Thin vs Thick" section in the paper
www.rrsoftware.com/prodinfo/triadapaper/triada.html

Re: thick? thin? binding

[Stephen Leake]

Immanuel Scholz <news@kutzsche.net> writes:

> Hi,
> 
> I read through 1 and a half Ada book and still doesnt catch what "thick" or 
> "thin" binding mean... 

It's not really an Ada concept; it's a general concept.

> I know "flat" binding from C or "name mangling" from C++. It this
> related to this?

No.

Let me give an example. Microsoft Windows has a large API, called
Win32. There is a "thin" binding to this, called Win32Ada.

The thin binding directly imports the C functions. So whereever the C
function uses a pointer, you get a parameter of type System.Address.
Wherever the C function uses a string, it must be null-terminated.

A "Thick binding" to Win32 would use either Ada access types or just
"in out" parameters, instead of System.Address. It would also use Ada
String instead of null-terminated strings. Typically, this requires
intermediate code to convert between the too. The amount of this
intermediate code determines the "thickness" of the binding.

An even thicker binding (like Windex,
http://users.erols.com/leakstan/Stephe/Ada/windex.html) goes beyond
that. It replaces the "window message handlers" of the Win32 API with
dispatching on Window_Type objects.

Hope this helps.
-- 
-- Stephe

Re: thick? thin? binding

[chris.danx]

"Immanuel Scholz" <news@kutzsche.net> wrote in message
news:aeqjst$96ip3$1@ID-100557.news.dfncis.de...
> Hi,
>
> I read through 1 and a half Ada book and still doesnt catch what "thick"
or
> "thin" binding mean...

A binding is an interface to external code (something that's not written in
Ada and/or which you have to import to use) like win32, OpenGL or a data
structures library written in fortran or C.

A "thin" binding is a 'one to one mapping to Ada of whatever interface the
foreign program provides'(1).  The Win32 binding for GNAT being a good
example, it's just a one to one mapping to the win32 api and makes you pity
C programmers :(

A "think" binding is more abstract, providing a nice 'Ada-like view of the
foreign program'(2).  They're the lovely bindings like GtkAda and Gwindows
which use object orientation, tasking, or anything else found in Ada to
provide a nice, neat interface for ppl to use (you almost don't need to know
what the underlying program looks like).


Chris

(1) & (2) Wheeler, Ada 95: The Lovelace Tutorial
          p174, section 16.3

Re: thick? thin? binding

[Stephen Leake]

Immanuel Scholz <news@kutzsche.net> writes:

> Hi,
> 
> I read through 1 and a half Ada book and still doesnt catch what "thick" or 
> "thin" binding mean... 

It's not really an Ada concept; it's a general concept.

> I know "flat" binding from C or "name mangling" from C++. It this
> related to this?

No.

Let me give an example. Microsoft Windows has a large API, called
Win32. There is a "thin" binding to this, called Win32Ada.

The thin binding directly imports the C functions. So whereever the C
function uses a pointer, you get a parameter of type System.Address.
Wherever the C function uses a string, it must be null-terminated.

A "Thick binding" to Win32 would use either Ada access types or just
"in out" parameters, instead of System.Address. It would also use Ada
String instead of null-terminated strings. Typically, this requires
intermediate code to convert between the too. The amount of this
intermediate code determines the "thickness" of the binding.

An even thicker binding (like Windex,
http://users.erols.com/leakstan/Stephe/Ada/windex.html) goes beyond
that. It replaces the "window message handlers" of the Win32 API with
dispatching on Window_Type objects.

Hope this helps.
-- 
-- Stephe

Re: thick? thin? binding

[Immanuel Scholz]

Stephen Leake wrote:

> A "Thick binding" to Win32 would use either Ada access types or just
> "in out" parameters, instead of System.Address. It would also use Ada
> String instead of null-terminated strings. Typically, this requires
> intermediate code to convert between the too. The amount of this
> intermediate code determines the "thickness" of the binding.

So the MFC is a thick binding from Win32-C-API to C++ ?  :-)
(Err, in some places this binding is really thin).


This also means thick binding is better but slower.

Immanuel Scholz

Re: thick? thin? binding

[tmoran]

> So the MFC is a thick binding from Win32-C-API to C++ ?  :-)
  Yes.
> This also means thick binding is better but slower.
It means it gains the usual Ada benefits, and it usually means it's at a
higher abstraction level, but the additional overhead is usually swamped
by the time spent inside Windows (or whatever) system calls.  Most of a
Windows binding is to IO - especially human speed GUI IO - which is slow
anyway.

Re: thick? thin? binding

[Ted Dennison]

Immanuel Scholz <news@kutzsche.net> wrote in message news:<aeqjst$96ip3$1@ID-100557.news.dfncis.de>...

> I read through 1 and a half Ada book and still doesnt catch what "thick" or 
> "thin" binding mean... I know "flat" binding from C or "name mangling" from 

A thin binding to a C library would be a package spec that contains a
bunch of subprograms that are "pragma interface"ed directly to the C
(or STDCALL or whatever) routines. Their parameters must be set up so
that C can process them correctly (strings must end with a null
character, etc.) Typically the names of the routines would be exactly
the same as the C routines, and you could just use the C
documentation.

A thick binding to a C library would present an interface of Ada
routines that take Ada-style data (no pointers, strings where every
character is valid and there is no terminiating null character, etc).
Typically they will also be much higher-level than the C facilities,
abstracting away much of the cruft (and perhaps some of the
functionality). The names of the subprograms may not bear much
relation to the C routine(s) they call, so a thick binding needs its
own documentation.

I usually try to operate in a middle ground ("semi-thick"), where each
C routine has a corresponding Ada routine whose job is to translate
Ada types and idoms into C types and idoms (and visa versa), and to
call the C routine. That way you don't loose functionality, but you
don't infect your Ada code with C stuff either. You still don't need
any new documentation for such a binding, as long as you comment what
C routines are called by what Ada routines.

Re: thick? thin? binding

[David Emery]

We had a tremendous discussion on this during the POSIX/Ada
(IEEE P1003.5) days.  It turns out that there are really two
dimensions to the problem.  We used "thick" vs "thin" to
describe the documentation.  If the binding has a fully rewritten
set of documents, it's a "thick binding".  If the binding comes
with a document that refers to the underlying binding, it's a "think
binding".  For example of the latter:
   The operation Open implements the C operation Open(), with the
   parameters mapped to Ada types as follows: ....
For the actual presentation of API itself, we used the terms "direct"
and "abstract".  A "direct binding" would make the interface pragmas,
etc directly visible.  (Hence the name.)  An "abstract binding" would
hide the underlying C (or whatever) API.  As an example of the latter,
most POSIX/C operations return -1 to indicate failure, and sett the
errno value.  We replaced this by the POSIX.POSIX_Error exception,
and provided an analog to errno.  Additionally, our errno (a function
in the package POSIX) was required to be tasking-safe.  Depending on
how both the Ada binding and the C library was implemented, a direct
binding, providing 
   errno : interfaces.c.int;
   pragma inport (convention => c, entity => errno);
might well not be tasking-safe.  

Although I'm certainly biased, I still think that the best discussion 
on the issues associated with Ada bindings is the rationale in 
IEEE Std 1003.5....  

         dave
         (editor for the first IEEE 1003.5 standard...)

Re: thick? thin? binding

[tmoran]

> Although I'm certainly biased, I still think that the best discussion
> on the issues associated with Ada bindings is the rationale in
> IEEE Std 1003.5....
  We stole, er, learned from, the POSIX standard for the development
of CLAW.  Sincerest form of flattery and all. ;)