Custom calling conventions

[Manu]

On 21 February 2012 19:02, H. S. Teoh <hsteoh at quickfur.ath.cx> wrote:

> On Tue, Feb 21, 2012 at 01:03:09PM +0200, Manu wrote:
> > So I was thinking about this extern(language) thing, the obvious ones are
> > supported, but it would be really nice to be able to implement custom
> > conventions for other languages/scripting languages.
> >
> > For instance, I'm thinking about Android, I have JNI binding code
> > everywhere, it's really ugly.
> > I'd love to be able to declare:
> >   extern(Java) int someJavaFunc(int x, float y)
>
> I wonder if there's a way to "outsource" (har har) extern declarations
> somehow so that instead of requiring the compiler to implement
> everything, it can forward most of the stuff to a library, e.g.,
> something that interfaces with JNI. The compiler would provide hooks to
> such a library so that it doesn't have to know how JNI works, but just
> forward calls to someJavaFunc(x,y) to a wrapper in the external library
> that can then do type translation, JNI mapping, etc..
>

... that's the essence of my whole proposal, except not quite like you
describe :)

This way, we don't have to bottleneck at the compiler when we need to
> support a new language binding, and we don't have to bloat the compiler
> with C, C++, JNI, PerlAPI (buahaha), what-have-you. Somebody can just
> write a library with the necessary hooks, and you can compile away at
> your leisure.
>

C/C++ is important to be known internally within the language, because to
make good use of these super-common languages, you need to know about the
differences in structure layout, and the language needs to generate code
accordingly (where to find the vtable/etc).
With the (typically VM based) languages I was referring to, there's no
direct linkage, all communication must be via some API, so the intrinsic
knowledge of foreign structures is not necessary in that case. You would
always need to understand the layout or contents of foreign structures via
some sort of marshalling api/class, since the VM is free to do whatever it
likes internally.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120221/ab02b96b/attachment.html>