I hadn't planned on talking about this for a while, but this log entry (which, alas, has no comments enabled so I can't comment directly there) brings up a point I do want to talk about.
Inter-langauge interoperability under Parrot. What, exactly, does it mean?
Well, it means that any language implemented on top of parrot that respects parrot's calling conventions may make use of any code written in any other language that respects Parrot's calling conventions. This means that your perl 6 program can load up and use perl 6, perl 5, python, ruby, and (maybe, if we thump it to do so) Forth library code, and call between it all transparently. It means that if something hands your code an object that you can call methods on it regardless of what language created the object. (Heck, each method the object has may be written in a different language)
The nice thing is that if we get things right, nobody should have to do anything special to make it work. You can snag an all-perl module off of CPAN and use it in your python program, at least once we get the perl 5 and python compilers working. Should all just work, and the only potential issue will be making sure that the standard libraries of all the languages in use are handy. That and potentially having two or three (or four, or five, or six...) libraries that do the same thing, only slightly differently.
Things are a bit different when it comes to modules with C code, though. We're not going to present an interface that's compatible with any of the existing languages--they all rely on intimate knowledge of the internals of their respective interpreters, and getting them to work would be a massive and ultimately fruitless endeavor, as there's no way we can really duplicate the internal semantics.
That doesn't mean, though, that modules with C code can only be used by one language--like the native modules, if Parrot can load up a module with C code, anything that runs on parrot can use it. It just means that there won't be a simple recompile-and-go for C code.
We will try and present at least a minimal compatibility layer, as feasible, as there are some routines that can be macro'd up just fine. Perl's newSViv routine generates a new scalar with an integer value that's passed in. That can be easily handled with a macro that allocates a new PMC and assigns an integer value to it. It's when you get to things like SAVETMPS and other code that depends heavily on the performance of the internals of the interpreter (in this case the perl 5 interpreter, though I know the internals of Python are as exposed as perl's though they are rather cleaner internals than what perl has) that there's no way to fake it with a few macros and some preprocessor slight-of-hand.
Still, that's OK. We knew that perl's XS modules would be a casualty of the switchover, and were willing to accept that. And we never had any expectation of python or ruby C code making it over. (Though we'll probably be able to do something similar for them--you never know, and neither do I as I've just not looked deeply enough yet)
Posted by Dan at April 19, 2003 05:17 PM | TrackBack (1)I don't know how much parrot cares about this, but, .NET makes calling into different language extensions easier than one might think. .NET can load in and run C libraries, and therefore, interfacing with (for example) PHP, is all about creating a thin wrapper that allocates zvals (which represent any and every variable) from base types.
Well, ok, that's kinda a lie, currently, PHP stores arguments on a global argument stack before a function call, and then the functions use an api to access the arguments. I should be very possible to modify the engine such that it passes the arguments directly to the function itself.
Posted by: Sterling Hughes at April 19, 2003 07:54 PMThe cross-language capabilities of parrot remind me of VMS, where you from any language that repected the calling conventions could call subroutines written in any other language respecting the calling conventions - even if you had to tweak the calls a bit from time to time.
I seem to recall that VMS is one of the inspiration sources for parrot...
Parrot can do the loading of external .dll/.so/.exe/.bundle/.dylib files (depending on one's OS and preferences) right now, via its NCI interface. It's a bit wordy at the low levels, but it is assembly after all, so it's not that bad. :)
So it ought to be possible, modulo some missing signatures (and adding them is easy, just patch parrot's call_list.txt file--send the patch to perl6-internals@perl.org if you would, and we'll roll it into the distro), to yank in the PHP interpreter now. I shall leave the thought of that as a good idea or not as an exercise to the reader.
Note that the call_list.txt file and the profoundly hackish way things are done under the hood is just a standin for a better way--the interface is good, it's just the implementation that needs replacing, and luckily that'll be doable, just not high on the TODO list as what we have does work, after a fashion.
Posted by: Dan at April 21, 2003 01:30 PMThere's a reason that you're reminded strongly of VMS' cross-language facilities--that's where a lot of this has been drawn from. I remember being both bemused and very annoyed the first time I went from a DEC OS (RSTS/E, actually) to a unix system and found that not only was there no interop between different languages but that two implementations of the same language (C, in this case) couldn't even talk to one another.
Posted by: Dan at April 21, 2003 01:32 PM