SWIG, Re: Language Bindings for Erlang

[Romain Lenglet]

On Saturday 27 May 2006 20:25, Gerd Flaig wrote:
> Romain Lenglet <rlenglet@REDACTED> writes:
> >> An Erlang add-on to SWIG would be nice...
> >>
> >>    http://www.swig.org/
> >>
> >> Preferably, one should be able to choose creating a
> >> port-program, linked-in driver, C-node interface.
> >> It is up for grabs; anyone ?
> >
> > I have been working on it for some time.
>
> would you please tell why you abandoned that approach and chose to
> roll your own instead?

Sorry, my sentence was ambiguous. I never considered SWIG.
I meant that I have been working on my own solution that would allow "to 
choose creating a port-program, linked-in driver, C-node interface." But not 
based on SWIG.

I believe that the SWIG approach is OK when languages are similar, and have 
similar data models, etc. But Erlang and C are so different, and the port 
driver model so... restrictive, that I believe that an approach that takes a 
C function signature and automagically generates an Erlang binding can work 
only for a limited category of signatures.
Or a lot must be done for a binding in additional hand-written wrappers, on 
the Erlang side and on the C side, to make the bound function signatures fit 
the limitations of the binding generator. See the previous email from Serge 
Aleynikov about the necessity to use C wrappers to overcome limitations of 
EDTK.
The problem is that a complete binding specification becomes scattered accross 
several files / wrappers, and maintenance becomes difficult. It is better to 
specify everything about a binding in one place, and to have consistency 
ensured automatically by tools (compilers...).

EDTK goes one step further than a SWIG approach, e.g. by allowing to specify 
when and how to map C data into integer identifiers, but since EDTK is also 
purely declarative and it offers little control without entering into the 
implementation details of the port driver, it is also not general enough.

The point about Dryverl is that it provides extensive *programmatic control* 
over the implementation of a binding, which is necessary to handle all kinds 
of bindings.
Dryverl has different objectives than SWIG and EDTK. Both aim at simplicity. 
Dryverl instead aims at flexibility and generality.


However, if anybody would write a SWIG-like binding generator to handle a 
limited category of simple cases, and which would generate Dryverl 
specifications (or even only skeletons of specifications), that would be very 
useful.


> I wonder what options there are for C++. The obvious approach seems to
> be to map classes to processes and method calls to sending a message
> (and receiving one if the method has a type different from void). But
> this only feels right for large objects.

You can make the "this" pointer explicit, and pass it as the first argument in 
normal function calls. On the Erlang side of the binding it would be a 
numeric identifier. On the C side of the binding, it would be mapped into an 
object pointer used as the target of C++ method calls.
The value map mechanism in Dryverl can be used to implement this easily.

Anyway, of course, this would require that you make all of your methods 
virtual. I don't see how to handle non-virtual methods (e.g. non-virtual 
destructors) in a clean way (and automatically!).

--
Romain Lenglet