Re: [boost] py_cpp and ILU?

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-12 09:50:12

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

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

I guess that's OK, as long as you don't care if what you write in the
abstraction layer can actually be represented in /any/ of the target
languages at all. Speaking personally, that doesn't sound very useful ;-)

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

Such languages already exist (c.f. CORBA IDL).

>     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?

What you call it doesn't matter. The point is that such systems historically
(and inevitably?) generate some language-specific code "templates" from the
IDL, which you have to use as the basis for, or adapt to, your
language-specific code. In the former case the IDL ends up imposing itself
on your language-specific code. In the latter case you end up having to
write adaptation code (usually more than is required by my system). These
are good tradeoffs to make for some systems, but I'm not targetting those.

>     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!

It's not really any worse than writing an interface specification in an IDL
(or UL as you like to call it).

> I would
> much rather get the job done by working around the currently poor
> mapping rather than rewrite that much code...  :)

"poor mapping"? Are you talking about auto-generated mappings like what
comes from Swig?

> 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?

I don't know, but it sounds like you are cut out for the job ;-)

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

Certainly it is. I know already of CORBA and COM and ILU. I'm sure there are
others. Perhaps EJB falls into this arena?

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

Perhaps I didn't add enough winking smileys when I wrote: "As soon as I can
get ahold of a C++ parser I can understand, of course, I'll be sure to
implement that ;->"
I don't expect to address this one soon. I think it would be terribly useful
for all kinds of C++ research to have a public-domain C++ parser with a
Python interface. We could use it to implement preprocessors to test
proposed language extensions, etc. But I'm /not/ promising that I'm going to
get one!

> So keep up the great work.
> But it is worth pursuing this idea sometime or the other.

We'll have to see how my userbase grows...

> 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?

I don't know much about Perl, but I doubt it has the right abstractions. For
example, does Perl have classes?

> 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?

I have no idea, but you sound like just the person to answer that question.
I did spend a few minutes looking at JNI to see if the same thing could be
done for Java, but it's not clear to me that it would work.

> 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?

Fair, but I can't really provide an answer without knowing more about the
internals of the other languages you'd want to support. These are big
projects; maybe someone else will be motivated to pursue them.

-Dave