From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,c3bb5e0c8d486559
X-Google-Attributes: gid103376,public
From: kilgallen@eisner.decus.org (Larry Kilgallen)
Subject: Quality of Thin Bindings (was: Programming X Windows...)
Date: 1996/10/23
Message-ID: <1996Oct22.223350.1@eisner>#1/1
X-Deja-AN: 191431454
x-nntp-posting-host: eisner.decus.org
references: <1996Oct22.171704.25522@ocsystems.com>
x-nntp-posting-user: KILGALLEN
x-trace: 846038070/7313
organization: LJK Software
newsgroups: comp.lang.ada
Date: 1996-10-23T00:00:00+00:00
List-Id: <comp.lang.ada>


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