On Mon, 2008-08-18 at 17:44 -0400, Michael Peters wrote: > Allison Randal wrote: > > > It's true that you can't get a Python array and expect it to respond to > > all the same method calls as a Tcl array. But that Python array is just > > another variable type, that accepts keyed access and method calls. You > > treat it as a user-defined data type, and read the documentation to find > > out what method calls it accepts. > > This is similar to how Inline::Java works. If you call a Java method you > get back a Java object. It's up to you to translate that into a Perl > object and you do that by reading the docs for that Java object and > calling it's methods. > > There is some magic to make Strings in Java be strings in Perl (same for > numbers, etc). But it's not too deep. I would expect that this kind of > shallow magic would be implemented in a Perl library. One each for the > most popular language. And it would probably just consist of some > methods that do casts. > > > While I don't expect every foreign data type to be immediately > > translated to a native type as soon as they touch the native code, I do > > expect it will be best practice to have any library in any language only > > return types native to its language. > > Absolutely. Some of the talk of automagic object translation was getting > me worried. If I'm calling a Java library it should return exactly what > it's documentation says (a Java object). Then I as the application > author should take the responsibility to make sure that code that uses > my library should get exactly what it's expecting.
Speaking just for myself, I had no expectation that we would be able to create a be-all end-all inter-HLL type mapper. Instead, I want to avoid forcing every HLL wrapper author to write a lot of very similar mapping scaffolding for common types, for every library and/or foreign HLL they wrap. I want to make the common cases easy -- and I'm happy to just keep the hard mappings possible. Common stuff should Just Work, without having to do a lot of pointless busywork. If I have to hand-write all the PIR to wrap something like Perl5's Term::ReadLine::GNU in another language, I'll go insane. Sure, I might reasonably choose to write a custom automated PIR generator to do all that, but I certainly don't want to write a new generator for each library I wrap. So I might try to generalize it to simplify writing the type mappings for the most common basic types. Pretty soon I begin to wonder how much of the generator is specific to the HLL I'm working on, and how much could be shared with other HLLs .... At which point the whole thing starts to look like something Parrot should provide, just like it provides a grammar engine, compiler framework, etc., even though there's no reason every HLL couldn't write their own tools from scratch (and some do). PCT just makes things SO much easier for common cases that it's like coming out of the dark ages. I think it would be mighty fine if HLL developers could get that feeling for inter-HLL call wrappers, too. -'f
