Changes between Version 1 and Version 2 of HLLInteroperability

Show
Ignore:
Timestamp:
09/12/11 02:37:00 (10 years ago)
Author:
jimmy
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • HLLInteroperability

    v1 v2  
    1919I'll attempt to summarize the points made in the remainder of the discussion. 
    2020 
    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. 
     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. 
    3333 
    3434The HLL interoperability discussion kicked off again here http://irclog.perlgeek.de/parrot/2008-07-22#i_404340