Ada bindings to Objective-C and Mac`Cocoa

6.11:
. cocoa-gnat is google-hosted startup that is more of an ad than a project
calling for 2 levels of GNAT Ada compiler bindings
to the Objective-C run-time API
and the Mac OS X Cocoa framework:
(1) A thin, low-level Objective-C-like Cocoa binding
written in Ada that corresponds one-to-one
with the Objective-C data types and runtime functions
(2) A thick, high-level Ada-like Cocoa binding written in Ada
that uses Ada features like overloading and genericity
to raise the level of abstraction while providing the benefits of
compile- and run-time checking
--. nothing is made,
just a bug report pointing to an Ada forum
that is pointing out that the project is empty .

. when thinking about interfacing Ada to Cocoa
my first idea was to think of Ada as
just replacing the C part .
. the Objective-C part is actually implemented in C
and can be dynamically linking code by
having C call a run-time module .

. I finally thought that the most bug-proof way to bind Ada,
was the same way I had in mind for adda:
use a lang-to-lang translator that translates your language
into the language that your target platform prefers .
. well, it turns out that such an idea was already tossed out,
known as an Objective-Ada pre-processor;
and here was the response:

It'll hurt ability of manipulating source code with 3rd party utilities
It is opposed to Ada spirit.

. others also said this:

Objective-C should be dealt with
the same way as COM on Windows;
except that you're using apple`BridgeSupport XML instead of IDL.

. BridgeSupport XML files are apparently for addressing
this problem:

. binding to an OO[obj'oriented] Lib in another language
is a job without end
as all libraries are constantly extended.

While BridgeSupport sounds good - will it work with GNUStep as well?
a. Cocoa is a superset of OpenStep
b. BridgeSupport files are automatically generated from headers

. other thoughts I had:

. the whole point of a pre-processor is to change the language;
but the primary mission of Objective-C
is something that ada has already addressed:
. the idea of dynamically interchangable modules
is the essence of Objective-C,
and in Ada we can do this by re-compiling the body of a package .
. the next time we run the system, it uses that body .
. every other feature depends on a c-based run-time;
and ada interfaces to c .
7.12:
. actually, another service of Objective-C
is that run-time that lets you call a variable function;
ie, instead of calling a particular function on a variable object,
everything can be variable:
call( [pointer to my obj], [pointer to name of function I want applied]) .
. Ada users would also need to follow a Reflection protocol,
where, for every class you define,
you have to declare similar information to a database
. the full power of the Objective-C 2.0 Runtime
is detailed in the Reference

this reference is useful primarily for developing bridge layers
between Objective-C and other languages,
You typically do not need to use the Objective-C runtime library directly
when programming in Objective-C

8.29: co.adda/macada/why is xcode changing its interface to new langs?:

. why is xcode changing its interface to new langs?
. this is another reason why I'm into
compilers that convert your lang into the platform lang .