Changes between Initial Version and Version 1 of HLLInteroperability

Show
Ignore:
Timestamp:
11/28/09 03:17:25 (10 years ago)
Author:
coke
Comment:

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

Legend:

Unmodified
Added
Removed
Modified
  • HLLInteroperability

    v1 v1  
     1^^ Why do we need Inter-HLL mapping? 
     2 
     3As the Perl 6 specification evolved, the "run multiple languages" feature became much visible. One problem, however, has been neglected, which is: 
     4 
     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? 
     6 
     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. 
     8 
     9^^ A can of worms? 
     10 
     11^^^ Donald Hunter's Notes 
     12 
     13I 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. 
     14 
     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. 
     16 
     17http://irclog.perlgeek.de/parrot/2008-07-21#i_403546 
     18 
     19I'll attempt to summarize the points made in the remainder of the discussion. 
     20 
     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. 
     33 
     34The HLL interoperability discussion kicked off again here http://irclog.perlgeek.de/parrot/2008-07-22#i_404340 
     35 
     36And again here http://irclog.perlgeek.de/parrot/2008-07-24#i_407655 
     37 
     38RT #57190 was raised to track the feature requirement. 
     39 
     40^^ Possible Approaches 
     41 
     42^^^ M * N direct mapping 
     43 
     44Pros 
     45 
     46* The best possible translations can be implemented for each situation. 
     47 
     48Cons 
     49 
     50* A very large number of translations required. 
     51* Ties every language to every other language, in terms of required translations. 
     52 
     53^^^ M + N source to base to target 
     54 
     55Pros 
     56 
     57* A manageable number of translations required, i.e. 1 per PMC. 
     58 
     59Cons 
     60 
     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. 
     65 
     66^^^ Freeze / Thaw 
     67 
     68Pros 
     69 
     70* Probably the simplest option 
     71 
     72Cons 
     73 
     74* Almost guaranteed to suck performance-wise. 
     75* Even this might run into interop issues when types flatten incompatibly. 
     76* Definitely forces copying. 
     77 
     78^^^ YAML 
     79 
     80Pros 
     81 
     82* An anti-pattern that might demonstrate the evilness of flattening. 
     83 
     84Cons 
     85 
     86* It might actually work. 
     87 
     88^^^ Use the appropriate vtable entries, rather than poking directly into PMC guts from your HLL 
     89 
     90Pros 
     91 
     92* Already implemented in Parrot 
     93 
     94Cons 
     95 
     96* Doesn't interoperate with HLL runtime ("a Perl 6 Object will never be the same as a Java Object") 
     97 
     98^^ Prior Art in other VMs 
     99 
     100^^^ JVM 
     101 
     102... 
     103 
     104^^^ CLR 
     105 
     106"Common Type System(CTS)"<http://en.wikipedia.org/wiki/Common_Type_System> 
     107 
     108^^^ etc (please add more) 
     109 
     110... 
     111 
     112^^ Research 
     113 
     114"Flexible Language Interoperability"<http://www.jot.fm/issues/issue_2007_09/article2/index.html>