Changes between Initial Version and Version 1 of HLLInteroperability

Timestamp:

11/28/09 03:17:25 (12 years ago)

Author:

coke

Comment:

migrate from  http://www.perlfoundation.org/parrot/index.cgi?inter_hll_mapping_notes

HLLInteroperability

@@ +1 @@
+^^ Why do we need Inter-HLL mapping?
+
+As the Perl 6 specification evolved, the "run multiple languages" feature became much visible. One problem, however, has been neglected, which is:
+
+> How am I going to use a java.util.Vector as a Perl 6 Array and how am I going to use a Perl 6 Array as a java.util.Collection?
+
+The point is that we're too much used to Perl, and in Perl we have a very strong set of 'built-in types', and this types usually solve most of the problems. Other languages, OTOH, have a much more strict feature-set in the 'built-in types' depending much more on additional libraries. Java is one of the better examples on that, because there are several different API sets for what in Perl can be seen as an Array, the same for Hash.
+
+^^ A can of worms?
+
+^^^ Donald Hunter's Notes
+
+I asked an innocent enough question on #parrot about type mapping between parrot and HLLs like Perl 6. See http://irclog.perlgeek.de/parrot/2008-07-21#i_403422 for the complete thread.
+
+I'm writing a sqlite driver for parrot and want to know how I can build structures in PIR that will be portable across multiple HLLs. For simple mappings from parrot to a single HLL this looks quite simple. I can create a ResizablePMCArray of Strings in parrot that will actually be a List of Strs in Perl 6 because the HLL mappings do their magic. But if I want to pass the structures between HLLs then the HLL mapping mechanism that we have today is not sufficient. This is where the discussion got interesting.
+
+http://irclog.perlgeek.de/parrot/2008-07-21#i_403546
+
+I'll attempt to summarize the points made in the remainder of the discussion.
+
+* HLL inteoperability is one of the stated core features.
+* There's no PDD for HLL interoperability.
+* We need a mechanism (based on .HLL_map?) for parrot to convert types from one HLL to types for another HLL. This will include translation between different PMC types.
+* There are no simple cases. Even Integers behave differently for different HLLs including different storage formats.
+* Perl 5 doesn't even have Integer or String, it has Scalar.
+* The mechanism will need to work for simple types such as Integer and String, for collections and more complex types.
+* The mechanism needs to support passing complex types as opaque objects so that Perl 6 can pass a BlackBox to Tcl and Tcl can then pass it back to Perl 6 later, for example.
+* A freeze/thaw mechanism might be the way to go.
+* Some people are in favour of automatic conversion, some are not.
+* Forcing an HLL to (intrusively) implement type mapping seems bad. Forcing the HLL to implement many mappings for other HLLs is evil.
+* It seems essential that parrot does all the heavy lifting so that HLLs are not unduly burdened with interop duties.
+* From japhb's OpenGL experience, it's clear that it's nice to be able to generate a foreign language's container, and manipulate it within the source language as an opaque object with lots of methods. The "at worst, everything is an object" design.
+
+The HLL interoperability discussion kicked off again here http://irclog.perlgeek.de/parrot/2008-07-22#i_404340
+
+And again here http://irclog.perlgeek.de/parrot/2008-07-24#i_407655
+
+RT #57190 was raised to track the feature requirement.
+
+^^ Possible Approaches
+
+^^^ M * N direct mapping
+
+Pros
+
+* The best possible translations can be implemented for each situation.
+
+Cons
+
+* A very large number of translations required.
+* Ties every language to every other language, in terms of required translations.
+
+^^^ M + N source to base to target
+
+Pros
+
+* A manageable number of translations required, i.e. 1 per PMC.
+
+Cons
+
+* Dumbs everything down to lowest common denominator representation of data types.
+* May force moving HLL PMCs into parrot where they can be shared and avoid translation.
+* Might end up being really slow.
+* Might force copying.
+
+^^^ Freeze / Thaw
+
+Pros
+
+* Probably the simplest option
+
+Cons
+
+* Almost guaranteed to suck performance-wise.
+* Even this might run into interop issues when types flatten incompatibly.
+* Definitely forces copying.
+
+^^^ YAML
+
+Pros
+
+* An anti-pattern that might demonstrate the evilness of flattening.
+
+Cons
+
+* It might actually work.
+
+^^^ Use the appropriate vtable entries, rather than poking directly into PMC guts from your HLL
+
+Pros
+
+* Already implemented in Parrot
+
+Cons
+
+* Doesn't interoperate with HLL runtime ("a Perl 6 Object will never be the same as a Java Object")
+
+^^ Prior Art in other VMs
+
+^^^ JVM
+
+...
+
+^^^ CLR
+
+"Common Type System(CTS)"<http://en.wikipedia.org/wiki/Common_Type_System>
+
+^^^ etc (please add more)
+
+...
+
+^^ Research
+
+"Flexible Language Interoperability"<http://www.jot.fm/issues/issue_2007_09/article2/index.html>