A vision for Parrot

[Neil Madden]

Donal K. Fellows wrote:

<snip interesting discussion, which mostly goes over my head :>

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