Re: thick bindings, was Re: Vulkan is here!

["Randy Brukardt" <randy@rrsoftware.com>]

"Olivier Henley" <olivier.henley@gmail.com> wrote in message 
news:66c5617d-49e6-40eb-9341-31c6664b1f6c@googlegroups.com...
On Thursday, February 18, 2016 at 11:21:26 PM UTC-5, tmo...@acm.org wrote:
> A thick binding, like any API, creates an abstraction intended to be
> easier and safer to program than coding at a lower level.  If you don't
> like the abstraction, don't use it - it's straightforward to code the
> necessary lower level thin binding instead.
...
>2. I questioned its architecture.

True thin bindings are trivial to make (and can be pretty much automated), 
but they completely lose any advantage to using Ada. Pretty much the only 
thing to do with a true thin-binding is use it to make a thicker binding, 
else you would be better off writing in C. (C has meager correctness 
checking, but you lose even that when you cross the boundary between 
languages. The use of Ada is actually a negative in such circumstances.)

What I've often advocated in such circumstances is the creation of a "medium 
binding". That is, eliminate the visibility at C issues without changing the 
essense of the binding (thus existing examples can be used with it). We did 
that for Windows waaay back before Claw; in the Windows 3.1 timeframe we 
made a medium binding for essentially all of the Windows interface of the 
time. It use the same operations but eliminated various c-isms:
    (1) Routines were named with underscores;
    (2) Overloading was used rather than unions (this was before 
Unchecked_Union was invented);
    (3) Boolean failure results were mapped to exceptions;
    (4) In out parameters were used rather than access parameters as much as 
possible (this requires inspection of the API in many cases);
    (5) null-terminated strings were converted into normal Ada string 
parameters where possible;
    (6) enumeration types were used rather than sets of constants if the 
values were distinct.

There probably were a few other changes that I've since forgotten. (Probably 
some typing was strengthened.)

(1) probably is a matter of taste (I find it near impossible to type 
identifiers that don't have the words separated by underscores, YMMV), and 
more recent improvements in Ada mean that (2) and (4) probably get at least 
partially handled by automatic conversion. But (3), (5), and (6) are the 
essence of Ada; without at least that you are gaining nothing for the 
significant loss of checking.

The important reason for having access to some low-level binding is so that 
one can directly translate examples into Ada. The idea is that a medium 
binding preserves that (one uses the same objects, same parameters [possibly 
better typed], same subprogram calls), but makes those calls more sensible 
Ada code, letting the compiler provide more help to the programmer.)

In contrast, a thick binding like Claw uses a different, more Ada-like 
overall design. Which means that one has to use only Claw examples -- most 
foreign language material doesn't work (at least not without a lot of mental 
translation). I agree with you that hiding the original API to that level 
can be a problem if your application doesn't fit into it's model - or you 
can't figure out how to do what you want even though you have a C example in 
front of you.

I would have preferred to concentrate on medium bindings, myself, but it 
didn't appear that we could sell such a thing (too hard to explain the 
value, especially to non-Ada programmers) so we wrote an ATIP-P proposal for 
Claw, not MAWB (Medium Ada Windows Binding). Which was accepted, so the 
route was cast...

                         Randy.