| 21 | | |
| 22 | | |
| 23 | | |
| 24 | | |
| 25 | | |
| 26 | | |
| 27 | | |
| 28 | | |
| 29 | | |
| 30 | | |
| 31 | | |
| 32 | | |
| | 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. |
