Re: Programming X Windows...

Re: Programming X Windows...

[G. Vincent Castellano]

% 
% I have never seen a thin Ada binding I liked, although I will admit
% to not having seen bindings from many sources.  The ones I have seen
% seem to be done "on the cheap" with no attempt to use derived numeric
% types to separate the "number of apples" cells from the "number of
% oranges" cells.
% 

First, with Ada 95's general access types, modular types
and access to subprograms, it is much easier to create thin
bindings whose typing corresponds reasonably closely to the
original interface.  Have you looked at any Ada 95 bindings?

Second, the determination of how and where to define derived
types is often impossible to determine from the 'original
text' of the interface you're binding to.  If the interface
was not originally designed with the subtype/derived type
issue in mind, it's pretty tough to graft one on as an 
afterthought.
 -----------------------------------------------------------------------
 -    G. Vincent Castellano, Sr. Software Engineer, OC Systems Inc     -
 -   gvc@ocsystems.com :: X/Ada WWW => http://www.ocsystems.com/xada   -
 -----------------------------------------------------------------------
 - "If virtual memory did not exist, it would                          -
 -   have become necessary for us to invent it."                       -
 -----------------------------------------------------------------------

Quality of Thin Bindings (was: Programming X Windows...)

[Larry Kilgallen]

In article <1996Oct22.171704.25522@ocsystems.com>, gvc@ocsystems.com (G. Vincent Castellano) quotes me and then writes:
> % 
> % I have never seen a thin Ada binding I liked, although I will admit
> % to not having seen bindings from many sources.  The ones I have seen
> % seem to be done "on the cheap" with no attempt to use derived numeric
> % types to separate the "number of apples" cells from the "number of
> % oranges" cells.
> % 
> 
> First, with Ada 95's general access types, modular types
> and access to subprograms, it is much easier to create thin
> bindings whose typing corresponds reasonably closely to the
> original interface.  Have you looked at any Ada 95 bindings?

I have looked at the Win32 bindings which come with ObjectAda 7.0
and it seems to me they rely excessively on a single integer type.
I gather that the same bindings are used by others, which is why
I did not raise this as a private matter with the ObjectAda vendor.
Portability between compiler vendors is important (and lack of it
causes a problem for Pascal on Macintosh).  Quality of those bindings
is also important.

> Second, the determination of how and where to define derived
> types is often impossible to determine from the 'original
> text' of the interface you're binding to.  If the interface
> was not originally designed with the subtype/derived type
> issue in mind, it's pretty tough to graft one on as an 
> afterthought.

Certainly just the text is not sufficient -- detailed knowledge of the
software involved is essential.  The set of bindings for which I am
most qualified to comment is Starlet, where there are many Ada 83
opportunities for derived numeric types which are not taken.  The
subtype:

   subtype CHANNEL_TYPE is SYSTEM.UNSIGNED_WORD;

for example, can never be used for any (valid) purpose besides
calling system services which take a value of that type.

I don't know what ACT might be doing to strengthen Starlet, but in
this particular case, and many others like it, I don't see anything
specific to Ada 95 that should not have been done for Ada 83 Starlet
as well.

There is a very similar 16 bit quantity in Starlet called a
Mailbox Unit, typically described as:

        MBXUNT          : in  UNSIGNED_WORD             := 0;

and it is easy to confuse the two.  I have confused the two twice
in my life (at least), separated by 15 years.  Neither was in Ada,
but inadequate bindings mean Ada would not have caught my error
either.  The nature of the failure mode does not lead to easy
analysis.

So I look at Win32 bindings and see the same casual approach we have
had in Starlet for years.  I realize such bindings work is not a big
moneymaker for anyone (especially since the goal is to share results),
but I am concerned about the issue of using the language to sort out
problems in everyday programming, not just space projects.

Larry Kilgallen

Re: Quality of Thin Bindings (was: Programming X Windows...)

[Mitch Gart]

Larry Kilgallen (kilgallen@eisner.decus.org) wrote:

: I have looked at the Win32 bindings which come with ObjectAda 7.0
: and it seems to me they rely excessively on a single integer type.

The problem is that Win32Ada doesn't represent an independent design 
of an API, it is a translation of a Microsoft API into Ada.  If 
Microsoft uses universal integer types everywhere, so must the binding.

Consider a simple example:

#define MASK1 1
#define MASK2 2
#define MASK3 4

In Ada is this a series of integer constants or an enumeration?  It's
tempting to say it should be an enumeration but then what about functions
in the binding that take integer parameters and return integer results?
Some of those functions may in fact take mask values or return mask results
from this enumeration, but how can the person writing the binding be sure
of the intentions of the original authors of the C software?  This kind of
question is one reason why Win32Ada is at such a direct one-for-one level
with the original C software.  

I and others have said many times that it would be good to think of a binding
like Win32Ada as a low level layer upon which other higher level layers could
be built.  I would encourage people to use Win32Ada as a base level and build
higher level Ada bindings to specific small parts of the Win32 API, for example
MAPI or OLE or ODBC or Video For Windows.

(snip)
: I don't know what ACT might be doing to strengthen Starlet
(snip)

I'm guessing that the people who invented Starlet had two advantages:

- VMS and Starlet were both Digital products so presumably the people working
  on Starlet were able to easily talk to the VMS people 

- DEC was at one time funding Starlet development and saw Ada as a money-making
  business area.

Mitch Gart