Changes between Initial Version and Version 1 of HLLInteroperability

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

migrate from


  • HLLInteroperability

    v1 v1  
     1^^ Why do we need Inter-HLL mapping? 
     3As the Perl 6 specification evolved, the "run multiple languages" feature became much visible. One problem, however, has been neglected, which is: 
     5> 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? 
     7The 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. 
     9^^ A can of worms? 
     11^^^ Donald Hunter's Notes 
     13I asked an innocent enough question on #parrot about type mapping between parrot and HLLs like Perl 6. See for the complete thread. 
     15I'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. 
     19I'll attempt to summarize the points made in the remainder of the discussion. 
     21* HLL inteoperability is one of the stated core features. 
     22* There's no PDD for HLL interoperability. 
     23* 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. 
     24* There are no simple cases. Even Integers behave differently for different HLLs including different storage formats. 
     25* Perl 5 doesn't even have Integer or String, it has Scalar. 
     26* The mechanism will need to work for simple types such as Integer and String, for collections and more complex types. 
     27* 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. 
     28* A freeze/thaw mechanism might be the way to go. 
     29* Some people are in favour of automatic conversion, some are not. 
     30* Forcing an HLL to (intrusively) implement type mapping seems bad. Forcing the HLL to implement many mappings for other HLLs is evil. 
     31* It seems essential that parrot does all the heavy lifting so that HLLs are not unduly burdened with interop duties. 
     32* 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. 
     34The HLL interoperability discussion kicked off again here 
     36And again here 
     38RT #57190 was raised to track the feature requirement. 
     40^^ Possible Approaches 
     42^^^ M * N direct mapping 
     46* The best possible translations can be implemented for each situation. 
     50* A very large number of translations required. 
     51* Ties every language to every other language, in terms of required translations. 
     53^^^ M + N source to base to target 
     57* A manageable number of translations required, i.e. 1 per PMC. 
     61* Dumbs everything down to lowest common denominator representation of data types. 
     62* May force moving HLL PMCs into parrot where they can be shared and avoid translation. 
     63* Might end up being really slow. 
     64* Might force copying. 
     66^^^ Freeze / Thaw 
     70* Probably the simplest option 
     74* Almost guaranteed to suck performance-wise. 
     75* Even this might run into interop issues when types flatten incompatibly. 
     76* Definitely forces copying. 
     78^^^ YAML 
     82* An anti-pattern that might demonstrate the evilness of flattening. 
     86* It might actually work. 
     88^^^ Use the appropriate vtable entries, rather than poking directly into PMC guts from your HLL 
     92* Already implemented in Parrot 
     96* Doesn't interoperate with HLL runtime ("a Perl 6 Object will never be the same as a Java Object") 
     98^^ Prior Art in other VMs 
     100^^^ JVM 
     104^^^ CLR 
     106"Common Type System(CTS)"<> 
     108^^^ etc (please add more) 
     112^^ Research 
     114"Flexible Language Interoperability"<>