Re: [boost] py_cpp and ILU?

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

hi,

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

<snip>
    >>  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
    >> (http://www.visualizationtoolkit.org).  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"...

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

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

<snip>

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

prabhu