Nontrivial examples of C interface with Ada

Nontrivial examples of C interface with Ada

[gressett]

Is there an example of a well-done, nontrivial interface to a C
library readily available on the web? Examples of communication with
C things defined like

some_struct *c_function(const char *things[]);

char *things[] = {
  "a",
  "b",
  "c",
  NULL
};

or

void c_routine(some_struct *p, void *otherthings[]);

or

int c_function2(int numbers[]);


would be very nice to have.
(Was it Mark Twain who said, "Learning by example isn't the best way,
it's the only way."?)

Re: Nontrivial examples of C interface with Ada

[tmoran]

>Is there an example of a well-done, nontrivial interface to a C
>library readily available on the web?
  The downloadable version of Claw at www.rrsoftware.com has Ada
style routines interfacing to about 500 C functions from the MS
Windows API.  That should give a reasonable coverage of at least
the kinds of C things MS does.  Having developed some of it, I
certainly believe it's "well-done" ;)

Re: Nontrivial examples of C interface with Ada

[Ted Dennison]

In article <9ckmisoo8k0dh1gcajhdgqtqjqc3bjmb25@4ax.com>,
  gressett@iglobal.net wrote:
> Is there an example of a well-done, nontrivial interface to a C
> library readily available on the web? Examples of communication with

I have a semi-thick level binding to the CLIPS expert system shell on my
web site at
http://www.telepath.com/dennison/Ted/AdaClips/AdaClips.html

Its not a complete binding to CLIPS, but I did have to handle some
tricky stuff in there. So together with the CLIPS reference, it ought to
make for some good examples.

"Semi-thick" is my term for my own favorite style for bindings. A
"semi-thick" binding is one that abstracts away typical stupid C
artifacts like pointer interfaces, return error codes, and
null-termiated strings. That way the interface "feels" like Ada. But it
doesn't abstract things so much that the C docs for the routine can't be
used for the Ada bindings.

As to how "well-done" it is, I can't really give an impartial opinion.
But I've been writing Ada C bindings for over 11 years, so I at least
*ought* to know what I'm doing. :-)

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Nontrivial examples of C interface with Ada

[Terry Westley]

<gressett@iglobal.net> wrote in message news:9ckmisoo8k0dh1gcajhdgqtqjqc3bjmb25@4ax.com...
> Is there an example of a well-done, nontrivial interface to a C
> library readily available on the web?

There are actually quite a few examples of nontrivial interfaces to C.
Go to almost any Ada site (http://www.acm.org/sigada/,
http://www.adapower.com, http://www.adahome.com) and look for
Ada bindings.

The one I wrote is an Ada binding to Tcl/Tk, see http://www.adatcl.com.

Right now, it has two levels of binding:

1) a thin binding to the C objects and functions using predefined Ada
    types which match the C types, and

2) a slightly thicker binding which uses Ada types in place of C types
    and exceptions instead of return codes.

I'm currently working on a thick binding which non-Tcl Ada programmers
will find much easier to use.

--
Terry J. Westley, Software Systems Engineering Supervisor
Veridian Engineering, Calspan Operations
twestley@buffalo.veridian.com   http://www.veridian.com/
-------------------------------------------------------
Author of TASH, an Ada binding to Tcl/Tk.
Visit the TASH web site at http://www.adatcl.com.
-------------------------------------------------------

Re: Nontrivial examples of C interface with Ada

[David Emery]

There's a discussion of interfacing issues (for Ada83) in the
rationale for the POSIX/Ada binding.  I also wrote a paper on this,
again Ada83, in TriAda 1992 or so.  

            dave

Re: Nontrivial examples of C interface with Ada

[Marin D. Condic]

gressett@iglobal.net wrote:
> 
> Is there an example of a well-done, nontrivial interface to a C
> library readily available on the web? Examples of communication with
> C things defined like
> 
The Win32ada binding to the Win32api is a major example of Ada bindings
to C stuff. It comes with the GNAT compiler and is probably available
from lots of other sources as well. (I think Aonix ships with it too,
but I have not looked at that product in a while.)

I personally find it a pain to use because of the large variety of types
for the same things, the constant use of error flags instead of
enumerated types and all the parameters are so C-ish that it doesn't fit
in with The Ada Way of thinking. (Some of this is just because the
Win32api is organically grown rather than engineered.) I'd prefer to see
a "thick" binding that simply hid all of the conversions, error flags,
etc. so that you had something that looked like Ada rather than
C-Written-In-Ada. But I suppose there is a need for the thin binding to
exist.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Nontrivial examples of C interface with Ada

[Scott Ingram]

"Marin D. Condic" wrote:
> 
> gressett@iglobal.net wrote:
> >
> > Is there an example of a well-done, nontrivial interface to a C
> > library readily available on the web? Examples of communication with
> > C things defined like
> >
(snip)
> 
> I personally find it a pain to use because of the large variety of types
> for the same things, the constant use of error flags instead of
> enumerated types and all the parameters are so C-ish that it doesn't fit
> in with The Ada Way of thinking. (Some of this is just because the
> Win32api is organically grown rather than engineered.) I'd prefer to see
> a "thick" binding that simply hid all of the conversions, error flags,
> etc. so that you had something that looked like Ada rather than
> C-Written-In-Ada. But I suppose there is a need for the thin binding to
> exist.
> 
> MDC
> --
...

The GTKAda binding is a very good example of a relatively thick binding
to 
C code.
-- 
Scott Ingram
Sonar Processing and Analysis Laboratory
Johns Hopkins University Applied Physics Laboratory

Re: Nontrivial examples of C interface with Ada

[Marin D. Condic]

Scott Ingram wrote:
> 
> The GTKAda binding is a very good example of a relatively thick binding
> to
> C code.

I have not looked at that, but it would be nice to see more bindings
that were thicker than the Win32ada binding. Mind you, I understand the
value of doing the thin bindings. You've got to keep up with the "real"
code and much of this sort of thing is done automatically. I doubt there
is a good way of automatically generating bindings that would translate
C-isms into Ada-isms, but ultimately, I want to access system routines
and such using normal Ada data structures and methods. Sometimes you may
lose access to every possible feature by doing this, or adding some
processing overhead to do conversions, but normally I'd consider it
worth it.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Nontrivial examples of C interface with Ada

[Marin D. Condic]

Ted Dennison wrote:
> "Semi-thick" is my term for my own favorite style for bindings. A
> "semi-thick" binding is one that abstracts away typical stupid C
> artifacts like pointer interfaces, return error codes, and
> null-termiated strings. That way the interface "feels" like Ada. But it
> doesn't abstract things so much that the C docs for the routine can't be
> used for the Ada bindings.
> 
That's about the depth I'd like to see bindings done. Get rid of
pointers to everything, use normal Ada strings, enumeration types for
return codes, etc. Of course you quite often run into cases where the
normal C way to do things is with a function and you have to make it
into a procedure in order to have it make proper sense in Ada, so you
always have little compromises to make. However, you at least want to
attempt to make it close to the original routine, only doing your best
to make it more Ada-ish.

One problem area I have found is with the use in C of error codes &
flags. The usual C method is to declare a long list of constants -
sometimes where the specific bits in the constants have particular
meanings (intended to be or'ed together). You would prefer enumerated
types, but there is often no clear grouping of the return codes.
Sometimes a constant is used for one type of thing and sometimes for
another (as in sometimes its a return status and sometimes its a
parameter). When the codes are used in the manner of flags (or'ed
together) you don't always have a good mapping onto an Ada method which
doesn't simply degenerate to an ugly C-ism. Maybe it would be useful to
develop a set of guidelines as to how to do these sorts of translations?
I certainly end up stumped sometimes as to what is the best choice and
some consistent guidelines would be handy.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Nontrivial examples of C interface with Ada

[Ted Dennison]

In article <392CC733.13BDDC84@quadruscorp.com>,
  "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:
> Ted Dennison wrote:
> pointers to everything, use normal Ada strings, enumeration types for
> return codes, etc. Of course you quite often run into cases where the

Often you can get rid of return codes altogether by using exceptions.
This works particularly well with the ever-popular "null pointer means
error" interface, and even better with the "a negative value means
error" interface.

> normal C way to do things is with a function and you have to make it
> into a procedure in order to have it make proper sense in Ada, so you

But somtimes you can go the other way. I often turn what was basicly
a "procedure with return error code" interface into a "function that
raises exception on error" interface.

Its funny how a mid-thick binding with exceptions can make a C library
routine easier to use in Ada than C. :-)

> One problem area I have found is with the use in C of error codes &
> flags. The usual C method is to declare a long list of constants -
> sometimes where the specific bits in the constants have particular
> meanings (intended to be or'ed together). You would prefer enumerated

> doesn't simply degenerate to an ugly C-ism. Maybe it would be useful
> to develop a set of guidelines as to how to do these sorts of
> translations? I certainly end up stumped sometimes as to what is the
> best choice and some consistent guidelines would be handy.

Hmm. There are of course some really weird interfaces out there,
particularly when you get into low-level OS calls. But I generally try
to stick to the rule that I use enumerations for #define'ed code sets
that are mutually exclusive (share significant bits) and packed boolean
arrays indexed by enumerations for code sets that don't. If there aren't
a lot of options, sometimes its just easier to make individual boolean
parameters for the options.

I don't think you are going to find consistent guidelines in this area
though, because a lot of this is highly contraversial. For instance,
some people don't like packed boolean arrays because the ordering of the
bits is implementation defined.

For me, the really tricky ones are the routines that return a pointer to
an object whose type is specified by the return value of another
parameter. As near as I can tell, you have to either make a separate
subprogram for each type and force the user to know what type he's
receiving when he makes the call, or you just throw up your hands and
return an address.


--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Nontrivial examples of C interface with Ada

[Ted Dennison]

In article <o%2X4.118$_M2.45406@news.pacbell.net>,
  tmoran@bix.com wrote:
>   Even though your code now looks Ada-ish and has strong typing,
> exceptions, etc. you will still be operating at a very low, C-ish,
> level of abstraction,
...
> send some html text, and close it.  Do you really want the ugly
> details of socket handling, or do you want a procedure Open, procedure
> Put, and procedure Close?

That's a very good issue. I prefer to think of it as an issue of power.
All of those calls and parameters are there for a reason. Once you have
done a "mid-thick" binding, any further abstracting of the binding to
make it simpler is going to inevitably loose some of the power of the
original. Sure, it will be easier to use, but you won't be able to do as
much with it as a C coder could with the original. As they say, "power
comes with a price". In this case, the price is complexity in the
interface.

Sockets are a very good example. Sure, I could give it a Text_IO
interface. But then how do I set my sockets to non-blocking? How do I
adjust the mbufs? How do I send a message to multiple recepients? How do
I write a server that detects TCP/IP timeouts from clients? I could go
on and on here.

Now if I know ahead of time that the user of this facility is one
program that will never ever need any more than a certain set of
functionality, then making a thick binding that perfectly encompasses
that functionality is the Right Thing to do. But for a general purpose
binding to a C-interface library, I don't think abstracting away
functionality is the right idea at all (unless its functionality put in
to deal with C's limitations). Some power user is bound to come along
and want that weird feature I abstracted away. I don't want anyone using
my bindings to ever feel like they are stuck in some rounded-scissors
Ada ghetto.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Nontrivial examples of C interface with Ada

[tmoran]

>OTOH, if you make it thin as possible, you don't have to do any docs at all
>- can't get simpler than that.
  Another advantage of a thicker binding is that its writer is forced to
find out the things that are not obvious, or simply false, in the C docs,
and use that knowledge in the implementation & documentation of the thick
binding.

Re: Nontrivial examples of C interface with Ada

[tmoran]

>For me, the really tricky ones are the routines that return a pointer to
>an object whose type is specified by the return value of another
>parameter. As near as I can tell, you have to either make a separate
>subprogram for each type and force the user to know what type he's
>receiving when he makes the call, or you just throw up your hands and
>return an address.
  Usually the kinds of objects the returned pointer points to, are
fairly highly related, in which case a return X'class may do the
job nicely.  In Claw, for instance, the different Device Independent
Bitmaps (different color resolution, palette use) are descendants of
a single type, so you can read an unknown .bmp file with
    function Read (Filename : in String)
        return Claw.Bitmaps.Root_DIBitmap_Type'class;
  Even more commonly, of course, an *input* parameter defines what
kind of entity the output pointer points to.  In that case, two different
Ada procedures fills the bill quite nicely.

Re: Nontrivial examples of C interface with Ada

[tmoran]

>any further abstracting of the binding to make it simpler is going to
>inevitably loose some of the power of the original.  Sure, it will be
>easier to use, but you won't be able to do as interface.
  The escape hatch is to have routines that let you get at the lowest
level entities and then make whatever system calls you want.
  function Get_Handle (Socket : in Root_Socket_Type'Class)
                return Socket_Handles;
        -- Returns the Windows handle of the socket.
  procedure Get_Socket_From_Handle (Socket : in out Socket_Type;
                                    Handle : in     Socket_Handles);
        -- Handle should be the Windows handle of an open, connected,
        -- blocking, or non-blocking but with no interrupts allowed,
        -- stream socket.
        -- Socket should be a closed CLAW Socket_Type'Class.
        -- On return, Socket will be open and have Handle as its
        -- Windows handle.
Of course it's also then up to the power user not to trip himself up
by his mixing of high and low level calls.

>But then how do I set my sockets to non-blocking?
  That's just a question of how thorough is the coverage of the thick
binding.  A lot can be done with a Text_IO style interface to blocking
sockets, with asynchrony being provided by suitable Ada tasking.  In
fact, Windows CE does not offer non-blocking sockets, so they expect
you to live happily with task switching instead of non-blocking sockets.
For Windows versions that do offer non-blocking sockets, Claw includes:
  type Async_Socket_Type is abstract new Socket_Type with private;
  -- A concrete non-blocking socket type must be derived from this
  -- and overriding When_xxx routines supplied.
which supplies the blocking socket routines plus primitives
  procedure When_Connect(Socket : in out Async_Socket_Type);
        -- Called when the socket becomes connected on an Open call.
  procedure When_Readable(Socket : in out Async_Socket_Type) is abstract;
        -- Called when "data is available to read" goes from False to True
and so forth.

Re: Nontrivial examples of C interface with Ada

[Ted Dennison]

In article <oGfX4.320$yf2.148802@news.pacbell.net>,
  tmoran@bix.com wrote:
> >any further abstracting of the binding to make it simpler is going to
> >inevitably loose some of the power of the original.  Sure, it will be
> >easier to use, but you won't be able to do as interface.
>   The escape hatch is to have routines that let you get at the lowest
> level entities and then make whatever system calls you want.

But for that escape hatch to be of any use, you need thin Ada bindings!

> >But then how do I set my sockets to non-blocking?
>   That's just a question of how thorough is the coverage of the thick
> binding.

Right. But this goes right back to the power issue. The more of the
power that was in the original that you put in your bindings, the more
it starts looking like the original interface.

> A lot can be done with a Text_IO style interface to blocking
> sockets, with asynchrony being provided by suitable Ada tasking.  In

Ugh! That's exactly the kind of heavy solution to a simple problem that
ticks off folks who are used to the easy solution. "Ada Ghetto"
syndrome. Why should I have to create a whole new task, plus God knows
what else to synchronize data between them, simply to do a non-blocking
I/O? Plus with some compilers, a blocking I/O blocks the entire Ada
program. If I were using C it would be a simple call.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Nontrivial examples of C interface with Ada

[tmoran]

> > blocking sockets, with asynchrony being provided by suitable Ada tasking.
>
> Ugh! That's exactly the kind of heavy solution to a simple problem that
  If it's good enough for Java or Windows CE ....  ;)

  Are we thinking about the same thing for "non-blocking sockets"?  I'm
talking about the kind (in Windows) where you get an "interrupt" (well, a
message in the Windows message loop, ie, good old Windows 3.1's version of
multitasking) when data arrives, or the socket disconnects, etc.  If you
just mean something like "read data, and let me do occasional status tests
when convenient to see when it's present and my program can process the
data", you don't need extra tasks for that.  You just use what I would
call a blocking socket, and interrogate status to see if there's data
available to read.

> But for that escape hatch to be of any use, you need thin Ada bindings!
 Well, clearly, thick bindings must be built on top of thin ones.  Nobody
has suggested a way to make a thick binding without having a thin one
underneath.

Re: Nontrivial examples of C interface with Ada

[tmoran]

> > "semi-thick" binding is one that abstracts away typical stupid C
> > artifacts like pointer interfaces, return error codes, and
> > null-termiated strings. That way the interface "feels" like Ada. But it
> > doesn't abstract things so much that the C docs for the routine can't be
> > used for the Ada bindings.
> ...
> However, you at least want to attempt to make it close to the original routine,
  Even though your code now looks Ada-ish and has strong typing, exceptions,
etc. you will still be operating at a very low, C-ish, level of abstraction,
Will you, for instance, use the OS'es semaphore function calls, or use
Ada protected records?  Callbacks via procedure access values, or by overiding
tagged record primitives?  Suppose you want to open a socket connection,
send some html text, and close it.  Do you really want the ugly details
of socket handling, or do you want a procedure Open, procedure Put, and
procedure Close?
  My preference is to start from the point of view of someone about to
design a spec for some abstraction (socket, Windows clipboard or dialog
box, etc).  "How would I do this in Ada?".  Then the body tries to
implement the abstraction using C calls.  Admittedly, sometimes the
simple, clean, abstraction needs some warts added to allow some of the
strange functions, or to fit the restrictions of, the underlying C, but
usually you can make something reasonably clean.  You can't just do a
translation of the C docs, but instead you have something that makes
sense and can be explained, usually, more simply.

Re: Nontrivial examples of C interface with Ada

[Geoff Bull]

tmoran@bix.com wrote:

>   My preference is to start from the point of view of someone about to
> design a spec for some abstraction (socket, Windows clipboard or dialog
> box, etc).  "How would I do this in Ada?".  Then the body tries to
> implement the abstraction using C calls.  Admittedly, sometimes the
> simple, clean, abstraction needs some warts added to allow some of the
> strange functions, or to fit the restrictions of, the underlying C, but
> usually you can make something reasonably clean.  You can't just do a
> translation of the C docs, but instead you have something that makes
> sense and can be explained, usually, more simply.

OTOH, if you make it thin as possible, you don't have to do any docs at all
- can't get simpler than that.

Re: Nontrivial examples of C interface with Ada

[Julian Day]

> Ted Dennison wrote:
>
> Sockets are a very good example. Sure, I could give it a Text_IO
> interface. But then how do I set my sockets to non-blocking? How do I
> adjust the mbufs? How do I send a message to multiple recepients? How do
> I write a server that detects TCP/IP timeouts from clients? I could go
> on and on here.

I hit on a similar issue a couple of years ago and 'dreamed' up what I
thought was quite a cute situation at the time.

pacakge Ada.Text_IO.C_Interface is
    type File_Descriptor_Type is new Interfaces.C.Int;    -- or similar
    function Associate (FD : File_Descriptor_Type) return
Ada.Text_IO.File_Type;
end Ada.Text_IO.C_Interface;

Since this is a child of Ada.Text_IO, it can fill out an appropriate
File_Type, and 'regular' Text_IO will then just work!

Julian

Re: Nontrivial examples of C interface with Ada

[Julian Day]

Julian Day wrote:

> I hit on a similar issue a couple of years ago and 'dreamed' up what I
> thought was quite a cute situation at the time.

Oops, that should be solution, not situation...

>
>
> pacakge Ada.Text_IO.C_Interface is
>     type File_Descriptor_Type is new Interfaces.C.Int;    -- or similar
>     function Associate (FD : File_Descriptor_Type) return
>        Ada.Text_IO.File_Type;
> end Ada.Text_IO.C_Interface;
>
> Since this is a child of Ada.Text_IO, it can fill out an appropriate
> File_Type, and 'regular' Text_IO will then just work!
>

(Before I get torn apart)

I think there were two fundemental problems as I remember.

    1. On the compiler I was using, the implementation of File_Type had been
hidden in Text_IO using

private
    type XXX;    -- I can't remember the name.
    type File_Type is access XXX;

    2. I did not have the body of Ada.Text_IO, to have a look at the
implementation of XXX on the compiler I was using.

Julian

Re: Nontrivial examples of C interface with Ada

[Marin D. Condic]

tmoran@bix.com wrote:
>   Even though your code now looks Ada-ish and has strong typing, exceptions,
> etc. you will still be operating at a very low, C-ish, level of abstraction,
> Will you, for instance, use the OS'es semaphore function calls, or use
> Ada protected records?  Callbacks via procedure access values, or by overiding
> tagged record primitives?  Suppose you want to open a socket connection,
> send some html text, and close it.  Do you really want the ugly details
> of socket handling, or do you want a procedure Open, procedure Put, and
> procedure Close?

Ultimately, I'd build that sort of stuff on top of the binding. What I
think constitutes a "binding" is just the interface to some existing
body of software. Yeah, it will look C-ish, but that's what it is. From
there, you have to define your own environment to do things with a true
Ada flavor. Until someone writes an OS in Ada..... :-)

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Nontrivial examples of C interface with Ada

[tmoran]

>Ultimately, I'd build that sort of stuff on top of the binding. What I
>think constitutes a "binding" is just the interface to some existing
>body of software. Yeah, it will look C-ish, but that's what it is. From
>there, you have to define your own environment to do things with a true
>Ada flavor.
  I would agree that including a Simplex LP solver along with elementary
matrix operations would be a confusing mix of conceptual levels.  But
Windows is already conceptualized at a fairly high level.  For instance,
there's a call to ask the user the name of a file, and then open it.  The
user may browse around, the request may look at files with only certain
extensions, etc.  If that's a single call, then I feel there should be a
single call to open a socket.  Windows itself presents a highly variable
level of abstraction, and smoothing that seems to me a legitimate and
useful function of a thick binding.  Heck, for some purposes a *really*
thick platform independent binding is desirable and that's certainly
pretty far from "just the interface to some existing body of software".
It presents an interface that lets the programmer easily do things that
would have been hard with a really thin binding.

Re: Nontrivial examples of C interface with Ada

[Marin D. Condic]

tmoran@bix.com wrote:
>   I would agree that including a Simplex LP solver along with elementary
> matrix operations would be a confusing mix of conceptual levels.  But
> Windows is already conceptualized at a fairly high level.  For instance,
> there's a call to ask the user the name of a file, and then open it.  The
> user may browse around, the request may look at files with only certain
> extensions, etc.  If that's a single call, then I feel there should be a
> single call to open a socket.  Windows itself presents a highly variable
> level of abstraction, and smoothing that seems to me a legitimate and
> useful function of a thick binding.  Heck, for some purposes a *really*
> thick platform independent binding is desirable and that's certainly
> pretty far from "just the interface to some existing body of software".
> It presents an interface that lets the programmer easily do things that
> would have been hard with a really thin binding.

I'm not sure you were getting my point. It was simply this: When do you
stop calling it a "binding" and start calling it a "subsystem" or
"application" or something else? CLAW, IMHO, is not a "binding" - it is
not a simple, one-to-one connection to underlying OS calls. It provides
its own design and implementation decisions about what a windowing
environment should be and, while this may parallel Windows concepts to a
large degree, it provides significant functionality in its own right.
Hence, it is not a "binding". (If a binding gets thick enough, it stops
being a binding?)

Win32ada *is* a binding because it makes no attempt whatsoever to extend
or limit the capabilities of the Win32api. If all I do is juggle the
parameters around a little bit so that there is still a one-for-one
mapping between my code and the Win32api, but my code provides types,
etc., which are of an Ada flavor, I'd still think it was a "binding" -
albeit, now a "thick" binding.

If someone used such a thick binding to build an application or
subsystem (such as CLAW) *that* would be the time to try to present to
the programmer a truly Ada-ish design. Its just that at that point, its
no longer a "binding", is it?

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Nontrivial examples of C interface with Ada

[tmoran]

>stop calling it a "binding" and start calling it a "subsystem" or
  Take a look at www.adapower.com in the list under "Win32 bindings".
Clearly several of those are what you would call subsystems, not bindings.
I suggest we adopt the idea of R-values of insulation thickness.  Then an
R-1 binding is Ada syntax, acceptable to an Ada compiler, but C in spirit,
ie, pass pointers, return flags, etc.  I'd say an R-4 binding has
exceptions and types, but still a 1-1 map between C functions and Ada
procedures.  I'd call CLAW an R-15, say, because it does indeed insulate
you from many of the characteristics of the C API, but still follows the
general outline.  In particular, your program built with CLAW will have
the "look and feel" of a Windows program to its users.  A platform
independent "subsystem", eg GtkAda or Tcl/Tk, would be labeled R-50 - you
have an internal environment that is almost totally independent of the
external environment.
  If you don't like that, then at least let's have a less general term
than "subsystem". ;)

Re: Nontrivial examples of C interface with Ada

[Robert Dewar]

In article <bk2Y4.339$q86.98765@news.pacbell.net>,
  tmoran@bix.com wrote:
> >stop calling it a "binding" and start calling it a
"subsystem" or
>   Take a look at www.adapower.com in the list under "Win32
bindings".
> Clearly several of those are what you would call subsystems,
not bindings.


I think a reasonable criterion for calling something a binding
is that it has the same functionality at roughly the same
semantic level. To call GtkAda a "binding" to Win32 in any sense
(even if we label it as R50) is definitely not helpful.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Nontrivial examples of C interface with Ada

[tmoran]

>Somehow, the concept of "binding" to me seems like it ought to be a
>one-for-one kind of "parallel" thing. If it starts abstracting from
>there, maybe it should have a different name.
  From the Posix Binding (IEEE Std 1003.5-1992)
B.1.4 Level of Binding
  There was a choice between a "direct" or an "abstract" binding of the
POSIX functions into Ada.  A direct binding is one where the base
POSIX.1(2) operations are mapped as closely as possible into Ada.  An
abstract binding groups the POSIX functionalities into abstract data
types, operations on those types, and packages of logically related
operations.
  The abstract binding has been chosen.

Clearly it's a matter of taste and judgement just where you stop calling
it a "binding" and give it a new name.  When we started work on Claw,
the intended user was an Ada programmer who wanted to write Ada programs
that ran on, and had the look and feel of, Windows programs.  Such a
person would probably be looking for a "Windows binding", and Claw
would fit his needs.  If instead you are a Windows programmer who
is coding in Ada, then a "thin binding" is probably just the ticket.
Perhaps, by analogy with hardware, Claw should be called a "Windows
driver", but I think that would confuse more than it clarifies.
"Binding" describes the function of Claw, even if it doesn't describe
its surface look, so I'm inclined to stay with "binding".

Re: Nontrivial examples of C interface with Ada

[Marin D. Condic]

tmoran@bix.com wrote:
>   Take a look at www.adapower.com in the list under "Win32 bindings".
> Clearly several of those are what you would call subsystems, not bindings.
> I suggest we adopt the idea of R-values of insulation thickness.  Then an
> R-1 binding is Ada syntax, acceptable to an Ada compiler, but C in spirit,
> ie, pass pointers, return flags, etc.  I'd say an R-4 binding has
> exceptions and types, but still a 1-1 map between C functions and Ada
> procedures.  I'd call CLAW an R-15, say, because it does indeed insulate
> you from many of the characteristics of the C API, but still follows the
> general outline.  In particular, your program built with CLAW will have
> the "look and feel" of a Windows program to its users.  A platform
> independent "subsystem", eg GtkAda or Tcl/Tk, would be labeled R-50 - you
> have an internal environment that is almost totally independent of the
> external environment.

O.K. I think we agree on concept at least. Something that maps
one-for-one is a different animal than something which has a high level
of insulation and portability. There are two questions: When does it
stop being a difference in degree and start being a difference in kind?
What name do you want to call it when it starts being a difference in
kind? (is a relational database just a "binding" to the OS file system
only with a higher level of insulation?)

Somehow, the concept of "binding" to me seems like it ought to be a
one-for-one kind of "parallel" thing. If it starts abstracting from
there, maybe it should have a different name. Where did I leave my
thesaurus? :-)
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Nontrivial examples of C interface with Ada

[Geoff Bull]

Ted Dennison wrote:

> But somtimes you can go the other way. I often turn what was basicly
> a "procedure with return error code" interface into a "function that
> raises exception on error" interface.
> 
> Its funny how a mid-thick binding with exceptions can make a C library
> routine easier to use in Ada than C. :-)

There are good examples of this in my binding to JNI.

In C you have to do a test to see if a Java exception has been thrown.
The Ada binding just raises an exception.