J. David Bryan wrote:
I know absolutely nothing about the Mac
I assume you genuinely don't know the background and history of the *Step/Cocoa API. It goes back to NeXT and was called NextStep. Later NeXT and SUN worked together to turn it into an open specification called OpenStep and this was implemented on all major Unix OSes. At that point the FSF started GNUstep as an open source implementation. Eventually Apple acquired NeXT and evolved the NextStep code base into Cocoa. This is now the primary (but not the only) GUI API on Mac OS X. In addition, it is the only GUI API on iPhone/iPad. There is also a Windows implementation called Cocotron.
In terms of installed base, its primary platform is the iPhone.
or its interfacing requirements, but there appears to be a project here:
http://code.google.com/p/cocoa-gnat/
...that might be applicable.
Ada does have support for interfacing to other languages (C, C++, COBOL, and Fortran), although this is in the form of pragmas that control data layout, e.g., row-major vs. column-major array order, and packages that provide types and procedures/functions compatible with the target language. The above project appears to be an interface package (called a "binding" in Ada) of this form.
See, for example:
http://www.adaic.org/standards/05rm/html/RM-B-1.html http://www.adaic.org/standards/05rm/html/RM-B-3.html
The trouble is that Objective-C is nothing like C, C++, COBOL and Fortran. When it comes to APIs, Objective-C is like Smalltalk.
Most Cocoa/GNUstep interfaces appear to be designed with a mindset of "This is just another C API" whereas they probably should be designed with a mindset of "I am going to have to interface to Smalltalk".
To those unfamiliar with Smalltalk it may help to think "This is like interfacing to SQL".
When you interface to SQL, you either allow plain SQL to be used verbatim and then send it off to an SQL engine as is, or you build a native interface layer that generates plain SQL and then send that off to an SQL engine.
What you probably do not want to do is build an interface that hooks into the SQL engine via a low-level C API that happens to be the one that the SQL engine uses internally simply because its written in C.
Unfortunately, the latter is the situation you encounter when interfacing to Objective-C. Like SQL, the it is a domain specific language that operates on a very high abstraction level. But unlike SQL, the Objective-C runtime does not have any (official) textual interface that allows you to send plain Objective-C statements to it to have them executed on the fly.
This means an implementor of an interface to Objective-C not only has to bridge the interface gap between the calling language and Objective-C, but they also have to bridge the abstraction gap between the high level of abstraction provided by Objective-C and the low level at which they must hook into the Objective-C runtime.
Unfortunately, the "just another C API" mindset often leads to an interface that doesn't bridge the abstraction gap and using the Objective-C library in the interfacing language is nothing like using it directly from Objective-C.
Not only that, but all too often, using an Objective-C library via such an interface is also an inferior experience compared to using a native library of the interfacing language.
It is no wonder then that those who use Cocoa/GNUstep natively like it because they see it the way it was designed and those who do not use it natively often don't like it because they see it through a "crippled" interface.
Many Objective-C developers have been in the latter camp before they started using Objective-C. Many of those "accidental" Objective-C developers often do not like the C side of the language much. Some of them then move on to design their own Objective languages, such as Objective-J, Objective-Lua, Objective Modula-2 etc etc etc.
Those designs not only do the interfacing, but they also bridge the abstraction gap. The simplest way to do that is of course to adopt the Objective-C syntax for message passing verbatim or at least something that resembles it very closely. For example Objective Modula-2 provides both Objective-C and Smalltalk message passing syntax.
However, bridging the abstraction gap doesn't necessarily require the adoption of Smalltalk or Objective-C syntax. For example, Closure Common Lisp has an Objective-C bridge with its own Lisp based syntax that is every bit as highly abstracted as Smalltalk and Objective-C. Maybe this comes down to the flexibility of Lisp and doing the same in other languages without adding special syntax is probably more difficult.
Still, when I look at cocoa-gnat, I am getting the impression that it leaves a lot to be desired in terms of bridging the abstraction gap, and that applies to both the thin and the thick binding.