Re: [boost] py_cpp and ILU?

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-11 09:57:37

----- Original Message -----
From: "Prabhu Ramachandran" <prabhu_at_[hidden]>

> Before I start anything else I'd like you to know that I am
> not a Computer scientist by profession.  I use c++ and python for my
> research and recreation.  Please bear with any errors/absurdities in
> what follows.

the absurder the better.

> I have been looking at tools that help use c++/c libraries via
> other programming languages.  For a list of such software you can look
> here:
> http://swig.sourceforge.net
> and here:
> http://swig.sourceforge.net/links.html
>
> There are quite a few tools that try to do c++ -> other
> language wrapping (I dont know if this is the right term).  All of
> them seem to share a lot of common features.  As is obvious, most of
> them do very similar things.  Each with its own limitations quirks
> etc.  After a cursory glance, one tool seems to stand out - ILU (Inter
> Language Unification)
>
> ftp://parcftp.parc.xerox.com/pub/ilu/ilu.html
>
> it even has the right name. :) But it seems to be designed along the
> lines of CORBA, maybe it is vice versa, whatever...
>
> It seems to abstract out an interface that can be used for a large set
> of languages.  This seems the right way to do things.

It depends what your goals are. Doesn't that leave you with
least-common-denominator abstractions?

> I havent looked
> at ILU in great detail but the points I want to make are related to
> generic library wrapping and are as follows.
>
> (1) It doesnt make sense for each wrapper creator to hack at her/his
> version of the parser etc. and redo work.  It is even worse if each
> library requires new wrapper code.  Tools like swig ease this process
> but not by much.  swig is not completely c++ compliant and doesnt
> support a large number of important c++ constructs like function
> overloading and templated class support.  Swig works ok for C
> libraries.  It is a step towards an inter langage library use but
> suffers from the lack of abstraction to a common interface language.

For casual lurkers, SWIG tries to parse your C/C++ source/header code and
automatically generate the wrapping code. Actually, that is only advertised
as secondary usage mode. In general, to use it reliably, you have to
describe the interface you want wrapped in an IDL (interface description
language) that looks like a subset of C++.

> (2) By specifying a Univeral Language/Interface (henceforth called UL)
> and providing wrappers from a specific language -> UL and also from UL
> -> specific language one saves a huge amount of time and pain.

Again, it depends on your goals.
ftp://parcftp.parc.xerox.com/pub/ilu/2.0b1/manual-html/manual_5.html seems
to say that ILU requires you to write your C++ interface in a particular IDL
(they call it an IL), which eventually imposes itself on your entire design
unless you write C++ wrapping code to interface the generated classes and
functions to your existing code. My system is designed to allow an existing
C++ library to be wrapped with little or no intrusion on its design.

BTW, the small amount of nearly-mechanical boilerplate code required to wrap
a C++ interface in my system could be seen as the IDL for my system. I agree
that it would be much more convenient if that code could be automatically
generated. As soon as I can get ahold of a C++ parser I can understand, of
course, I'll be sure to implement that ;->

> (a) Take for instance the case of the GTK library.  GTK is
> written in C but there are all kinds of languages that are
> currently supported.  Each of these ports would have taken a
> quite a lot of work.  If the developers had concentrated on a
> UL to specific language wrapper then their efforts would
> become completely general and it would be possible to wrap
> *any* other library to this particular language.

This is certainly an example that might have benefited from such an approach
since people want to use it from all kinds of languages. On the other hand,
they didn't, so an approach that allows non-intrusive wrapping might be
really useful, right?

> (b) Even if some wrappers are partial it still prevents a ton
> of replicated work.
>
> (c) I guess this is beginning to sound like CORBA but I hope
> you folks get the drift of what I mean.
>
> I have no idea if this is possible with ILU.  But it sure seems to
> make sense to add an abstraction layer between languages.  I admit
> this is a non-trivial task but well worth it in the long run.
> Projects like ILU show that something along these lines is possible.

Certainly, it is possible, but AFAIK has a downside. I am not an expert in
this stuff so maybe someone else would like to pipe up.
Non-expertly-speaking: typically, the classes you expose in your interface
must be derived from, e.g. ILUClass, CorbaClass, or COMObject, must eschew
multiple-inheritance, and must be specified in some quirky IDL which doesn't
match either C++ or the "other" language if there's another language
involved. I'm sure there are others.

> I cant even begin to think how useful a generic tool like this would
> be to the software community.  There are a ton of libraries out there
> if inter language wrapping was generalized it would be truly amazing.
>
> I am sure others have thought of this before.  I just wanted to run
> this idea by you folks.

Like I said, not an expert in this area, but I think there have been many
such efforts, and I expect research in that area to continue. I'm not sure
that's a problem I'm interested in addressing, however.

ambitious-but-not-that-ambitious-ly y'rs,
dave