Re: [boost] py_cpp and ILU?

From: Prabhu Ramachandran (prabhu_at_[hidden])
Date: 2000-10-12 04:55:45

hi,

        My original post has been a little misunderstood.  I think I
am to blame because I gave too much emphasis to ILU.  Here are some
clarifications.

1. I spoke about ILU not as a goal or something that has to be used by
py_cpp or any other library translation tool.  I just wanted to
illustrate the idea.  Realising that ILU was more like CORBA I changed
gears and called the layer of abstraction a Universal Language (UL).
CORBA is a different beast and since ILU is kind of similar it was not
the best choice for my example.

2. What I really meant was to have an abstraction layer between
languages that is a *superset* of what exists for all languages.  

3. This UL that I talked about is targetted purely towards wrapping
libraries from one language to another.  So one does not need to
create a complete language translator.  That would be far more
involved.

4. I did not mean that py_cpp should implement this, but maybe
somebody here would fancy the idea, think about it and maybe one
day...

>>>>> "David" == David Abrahams <abrahams_at_[hidden]> writes:
<snip>
    >> 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.

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

        Not necessarily.  The UL could always be a superset but the
mapping to particular languages can be made dumber as and when
necessary.  The point is that the structure of each language is well
defined.  All we need to do is map between different structures.

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

        Yes, for C libraries (ANSI C is easiest) one basically sticks
the header file into this "IDL" file and runs swig on it.  Voila!
perl, python, tcl bindings.  I wrapped a simple IrisGL like library
called Ygl like this.  Pointers didnt work so I had to add a couple of
new functions to deal with some issues.  Even this is not really
ideal.

    >> (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.

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

        Yes, my fault.  I never meant that you *should* use ILU.  I
agree, using ILU to do this is a bad choice.  But what if there is a
new standard common lang interface called UL?

    David> BTW, the small amount of nearly-mechanical boilerplate code
    David> required to wrap a C++ interface in my system could be seen
    David> as the IDL for my system. I agree that it would be much

        I agree that for a given class this amounts to a small amount
of boilerplate code.  py_cpp is cool at that, really.  But consider a
massive library.  As an example take the Visualization Toolkit - VTK
(http://www.visualizationtoolkit.org).  It has well over 600 classes!
I wouldnt think of writing all that boilerplate code by hand!  I would
much rather get the job done by working around the currently poor
mapping rather than rewrite that much code...  :)

    David> more convenient if that code could be automatically
    David> generated. As soon as I can get ahold of a C++ parser I can
    David> understand, of course, I'll be sure to implement that ;->

        Yes, please.  A huge number of people would be very grateful.
I promise you there will be a ton more of cool python libs if this
happens. :)

    >> (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.

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

        Exactly.  A UL fits in here perfectly.  As I see it, providing
a Universal Language (UL) should enable non intrusive wrappings by the
following method.

1) C++ headers -> translated to UL (no code added to the c++ lib)

2) A UL based library is created that links to the C++ library

3) Using the UL_lib and the UL definitions a python binding is
created.

So one basically needs a language to UL and a UL to languge
translator.  Sounds simple.  But most probably hard to get working?

<snip>
    >> I am sure others have thought of this before.  I just wanted to
    >> run this idea by you folks.

    David> Like I said, not an expert in this area, but I think there
    David> have been many such efforts, and I expect research in that

        I'd really like to know if this is the case at all.

    David> area to continue. I'm not sure that's a problem I'm
    David> interested in addressing, however.

        Sure, that is your choice and as I see it there is no point in
doubling your work now.  Esp. when the whole idea is possibly flawed.

        I guess I am becoming greedy.  It is already cool enough to
have py_cpp doing what it does and with your promises to get a C++
parser I really should'nt trouble you.  So keep up the great work.
But it is worth pursuing this idea sometime or the other.

        Actually, come to think of it, why cant c++ be used as the UL?
In this case a language map would mean translating code from a
specefic language to c++.  At some level this must be happening
anyway, python is implemented in C, right?  So is perl.  perl is going
to be rewritten in c++ I heard.  But there is a problem, I think it is
easier to convert c++ code that can be used by perl/python etc. But it
is harder to do the reverse.  Is this true?  Then atleast for any
complied library (as against an interpreted one) it should be possible
to provide language bindings, relatively easily.  I therefore have the 
following questions:

1) Would it be possible to abstract out how you map c++ to python in
some sort of generic way so that a perl_cpp person could just "extend"
py_cpp and add the right functions to do it in perl and obtain perl
mappings with minimum fuss?

2) If you get the c++ parser going could you provide a generic
interface so that other languages can be plugged in?

        Since you know the internals of py_cpp I guess these are fair
questions to ask?

thanks,
prabhu