Boost logo

Boost :

From: Prabhu Ramachandran (prabhu_at_[hidden])
Date: 2000-10-14 10:19:15


        Sorry about the delayed response.

>>>>> "David" == David Abrahams <abrahams_at_[hidden]> writes:

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

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

        You can always approximate. Most things, after all, are
approximations. :)

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

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

AFAIK, CORBA is something that mediates between calls. So if one
makes a call to a CORBA'd library CORBA takes care of the translation
_during_ runtime. The UL that I am talking about will help generate a
library, just as py_cpp does, that will translate language specific
details during the time the library is built. Is this not a serious

>> 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> What you call it doesn't matter. The point is that such
    David> systems historically (and inevitably?) generate some
    David> language-specific code "templates" from the IDL, which you
    David> have to use as the basis for, or adapt to, your
    David> language-specific code. In the former case the IDL ends up
    David> imposing itself on your language-specific code. In the
    David> latter case you end up having to write adaptation code
    David> (usually more than is required by my system). These are
    David> good tradeoffs to make for some systems, but I'm not
    David> 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
>> ( It has well over 600
>> classes! I wouldnt think of writing all that boilerplate code
>> by hand!

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

Yes, it isnt any better. But the point is this. Let us say I have a
C++ parser that takes C++ code and then converts it to this UL. Now
someone writes a tool that takes UL code and writes C/C++ code that
generates a python library. Now if someone wants to write a perl
module the person just has to write an UL to perl library tool.
Essentially the work of the C++ -> UL converter, or the C++ parser is
not repeated. The same applies to Tcl/java or whatever. I admit that
this may not be possible at all.

        The above ideas may not be the goals of py_cpp, I can
understand that. But I dont think that this idea is similar to ILU or
CORBA. But anyway forget it. I think I am wasting your time with
impossible ideas. :)

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

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

        Yes. But currently, the VTK folks dont use SWIG. They
generate their own "mappings"...

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

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

        Heh. Not really. :) Just an idea. Ideas are dime a dozen
but implementors are few.

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

    David> Perhaps I didn't add enough winking smileys when I wrote:
    David> "As soon as I can get ahold of a C++ parser I can
    David> understand, of course, I'll be sure to implement that ;->"
    David> I don't expect to address this one soon. I think it would
    David> be terribly useful for all kinds of C++ research to have a
    David> public-domain C++ parser with a Python interface. We could

        Ahhh. Ok. Will see if I can do something about it.

    David> use it to implement preprocessors to test proposed language
    David> extensions, etc. But I'm /not/ promising that I'm going to
    David> get one!

        Ok. I understand.

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

        Someone else clarified that it does.

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


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

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

Yeah. It really makes things more complex. So forget it. Just had
an idea that I thought would be useful to share.

Now to something more concrete. About this C++ parser. What exactly
do you want? I really dont know much about this kind of stuff. Would
it be possible to create a c++ parser in python or does it have to be
in c++? Python would be the easiest to code, right? If it is not
that hard maybe I can take a shot at it and brush up my re. Or is
this thing non-trivial?


Boost list run by bdawes at, gregod at, cpdaniel at, john at