Call for ACE participation

Call for ACE participation

[Oliver E. Cole]

Ada Common Environment: Call For Participation

The Ada Common Environment Working Group of the Ada Resource
Association is accepting candidates for adoption as "Ada Common
Environment Bindings".  One binding from each area will be designated
as "ARA Common" and will be recognized by member companies of the 
Ada Common Environment Working Group.

The nominated binding must be an existing implementation. It must be
freely distributable, though not necessarily in the public domain.
Bindings which do not rely heavily on vendor-specific language features
are a plus.

Nominations will be accepted until November 8th, 1996 and should be
submitted via e-mail to ada-common@gnat.com or in via hardopy to
Steven W. North
Steven W. North
Secretary, ACE WG
c/o OC Systems Inc
9990 Lee Hwy Ste 270
Fairfax VA 22030-1720

The nomination period will be followed by an 8 week review period with
the goal of selecting suitable candidate(s).

Nominations are being accepted for the following areas:

1) The X Window System (X11)
2) Win32 (MicroSoft Win32)
3) ODBC (Open Database Connectivity)
4) MFC (Microsoft Foundation Classes)
-- 
------------------------------------------------------------------------------
Oliver E. Cole                                               oec@ocsystems.com
OC Systems, Inc.          http://www.ocsystems.com/             (703) 359-8165

Re: Call for ACE participation

[Dr. John B. Matthews]

In article <1996Oct8.194417.16693@ocsystems.com>, oec@ocsystems.com
(Oliver E. Cole) writes:
> Ada Common Environment: Call For Participation
[...]
> Nominations are being accepted for the following areas: 
> 1) The X Window System (X11)
> 2) Win32 (MicroSoft Win32)
> 3) ODBC (Open Database Connectivity)
> 4) MFC (Microsoft Foundation Classes)

Would you be interested in MacOS bindings?

John
----------------------------------------------------------------
Dr. John B. Matthews
jmatthews@nova.wright.edu; john_matthews@ccmail.dayton.saic.com
"Whom the gods would destroy, they first invite to program in C"

Re: Call for ACE participation

[Larry Kilgallen]

In article <1996Oct8.194417.16693@ocsystems.com>, oec@ocsystems.com (Oliver E. Cole) writes:

> The Ada Common Environment Working Group of the Ada Resource
> Association is accepting candidates for adoption as "Ada Common
> Environment Bindings".  One binding from each area will be designated
> as "ARA Common" and will be recognized by member companies of the 
> Ada Common Environment Working Group.

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.

Is this Working Group likely to have anything better to choose from,
or are we condemned to live with bindings which do not offer the full 
power of Ada for a long time?

Or is there a periodic augmentation of the bindings list intended ?

I am _not_ seeking thick bindings, just stronger typing on thin ones.

I am _not_ suggesting that everyone else in the world should volunteer
to write what I want, but I would like to understand if others see a
problem here or if there is some explanation I do not understand.

Larry Kilgallen

Re: Call for ACE participation

[Robert Dewar]

Larry said

"Is this Working Group likely to have anything better to choose from,
or are we condemned to live with bindings which do not offer the full
power of Ada for a long time?"

Thick bindings have to be built on top of thin bindings in any case.
For many purposes thin bindings are far preferable to thick bindings.
Ultimately we perhaps need both, but reliastically, we will have only
thin bindings for many applications.

Re: Call for ACE participation

[Larry Kilgallen]

In article <dewar.845433836@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Larry said
> 
> "Is this Working Group likely to have anything better to choose from,
> or are we condemned to live with bindings which do not offer the full
> power of Ada for a long time?"
> 
> Thick bindings have to be built on top of thin bindings in any case.
> For many purposes thin bindings are far preferable to thick bindings.

Yes, I certainly want thin bindings in many cases, but I would think of
a binding which mirrored OS calls but described them with different
derived numeric types for "window number" and "command number" as
still being "thin".  I have to do as much work to use it, but more
of my mistakes will be automatically detected.

> Ultimately we perhaps need both, but reliastically, we will have only
> thin bindings for many applications.

I already understand the idea that such things take work,
but I did not know if there was some reason other than the
effort required.  Clearly provision of something better
than today's bindings will not prevent someone with using
today's.

Larry Kilgallen

Re: Call for ACE participation

[Jon S Anthony]

In article <dewar.845433836@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Thick bindings have to be built on top of thin bindings in any case.
> For many purposes thin bindings are far preferable to thick bindings.
> Ultimately we perhaps need both, but reliastically, we will have only
> thin bindings for many applications.

Yes.  In fact, I don't believe that thick bindings are a good idea
outside of specific applications or at least well scoped application
domains.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Call for ACE participation

[Robert Dewar]

Larry said

"Yes, I certainly want thin bindings in many cases, but I would think of
a binding which mirrored OS calls but described them with different
derived numeric types for "window number" and "command number" as
still being "thin".  I have to do as much work to use it, but more
of my mistakes will be automatically detected."

Now I am puzzled, it is not the case that the thin bindings we are
talking about avoid the use of derived numeric types. In fact one
discussion we have had with respect to one of the bindings was
precisely whether or not to use derived types in a particular
situation, and we concluded that the attempt to use derived types
was flawed because it generated so many annoying and unhelpful
conversions.

The issue of when and when not to use derived types is an interesting
one, but I don't see it has anytyhing to do with bindings being thick
or thin!

Re: Call for ACE participation

[Stanley R. Allen]

Larry Kilgallen wrote:

> The method you describe (try for derived types, but skip them in
> cases where they cause trouble) seems appropriate to me, but was
> obviously not used in the Ada bindings I have needed so far.
> 

Speaking of which... why not use private types in your thin binding?
I've seen this technique used before -- an old Xlib binding defined
all of the basic X resource identifiers (Atom, Font, Bitmap, etc) as
private types which internally were derived from Integer.  It was
nice (certainly it was the intent of the X consortium, even though
their language did not support the concept), and it was still thin.

-- 
Stanley Allen
s_allen@hso.link.com
(281) 280-4445

Re: Call for ACE participation

[Michael Feldman]

In article <dewar.845433836@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:

>Thick bindings have to be built on top of thin bindings in any case.
>For many purposes thin bindings are far preferable to thick bindings.

One advantage of thin bindings is that programmers experienced with
the original library will see familiar stuff on the Ada side. I
discovered this originally when I first got the Meridian Ada 83
compiler for Win 3.1. I found I could use Petzold's book immediately,
because the library structures, types, and operations were easy
to translate mentally into Ada. (And I was a real novice at writing
Windows apps, so having a good text really helped).

I rediscovered this over the summer, in writing some Mac apps to
provide examples and explore the GNAT MacOS binding. I could go
straight to a couple of books I had, and also to Inside Mac, to find
the explanations I needed.

>Ultimately we perhaps need both, but reliastically, we will have only
>thin bindings for many applications.

Once again it's a question of market demand. Who will write the thick ones
(and the competent documentation and tutorials to go with them)?

Mike Feldman

Re: Call for ACE participation

[Larry Kilgallen]

In article <dewar.845506966@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Larry said
> 
> "Yes, I certainly want thin bindings in many cases, but I would think of
> a binding which mirrored OS calls but described them with different
> derived numeric types for "window number" and "command number" as
> still being "thin".  I have to do as much work to use it, but more
> of my mistakes will be automatically detected."
> 
> Now I am puzzled, it is not the case that the thin bindings we are
> talking about avoid the use of derived numeric types. In fact one
> discussion we have had with respect to one of the bindings was
> precisely whether or not to use derived types in a particular
> situation, and we concluded that the attempt to use derived types
> was flawed because it generated so many annoying and unhelpful
> conversions.
> 
> The issue of when and when not to use derived types is an interesting
> one, but I don't see it has anytyhing to do with bindings being thick
> or thin!

I do not believe I was the one who introduced the word "thick" to
this thread.  I was merely looking for a baselevel of using derived
numeric types (something which takes human effort beyond what can
be done with mechanical translation of bindings from lesser languages).

The method you describe (try for derived types, but skip them in
cases where they cause trouble) seems appropriate to me, but was
obviously not used in the Ada bindings I have needed so far.

Larry Kilgallen