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
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
>> 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
>> (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"...
>> So one basically needs a language to UL and a UL to languge
>> translator. Sounds simple. But most probably hard to get
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
>> 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk