From: Neil Madden Date: 2002-11-13T02:50:11+09:00 Subject: Re: A vision for Parrot Donal K. Fellows wrote: > > BTW, how does Parrot handle calls to foreign code? The docs I've seen are on > the hazy side, and integration with existing C, C++ and FORTRAN monoliths is > (alas) all too important in particularly commercial development. > On this particular point; has anyone thought of writing a unified C-API for Tcl, Perl, Python, Ruby, (Java) etc? What I mean by this is that each of these languages can be extended in C, and quite often are. Also, whenever I see interesting new C/C++ libraries implemented, I also tend to see seperate language bindings for each of these languages. This seems like a massive duplication of effort. Would it be possible to abstract over the C API's of these languages to a common core of functionality which all share (e.g. getting an interpreter handle, registering a command, setting a variable etc)? I have only dealt with Tcl's C interface, so this may be too difficult, but it seems like it would be a huge step forward. In terms of problems implementing this, I can see several problems: 1. Method of calling C-coded procedures. In Tcl, arguments are passed to C procedures as Tcl_Obj's. Obviously this would be different for Perl or Python. Is it possible to come up with an API which can convert to the appropriate object type, or to some intermediate type? 2. Accessing functions which are not present in all languages. I'm sure there are API's in Tcl which only make sense with respect to Tcl, and probably the same in the other languages. So, how would one create a general API which allows you to call language specific APIs? In the same way one handles platform specific APIs? 3. Versioning. Which language versions are compatible with which abstract API? I can see this one becoming insane over time. However, there are people with much more experience with these issues than me, so there might be a way. 4... probably more, this is all coming of the top of my head. Hmm.. the more I think about this, the more problems it seems to present. I'd love to be able to write an extension, and have it instantly work with x different langauges. Also, I'd love to be able to use Python and Perl extensions from Tcl, without loading seperate interpreters and all that. Am I dreaming of an impossible Utopia? Neil "soo naive" Madden -- package r Tkhtml;package r http;pack [scrollbar .v -o v -co {.h yv}] -s right\ -f y;pack [html .h -ys {.v set}] -f both -e 1;bind .h.x <1> {eval g [.h href %x\ %y]};proc g u {set t [http::geturl $u];.h cl;.h p [http::data $t];http::cleanup\ $t;.h co -base $u};g http://mini.net/tcl/976.html;proc bgerror args {};# NEM :-)