On Wed, Jul 23, 2008 at 11:02 AM, chromatic <[EMAIL PROTECTED]> wrote: > On Tuesday 22 July 2008 21:58:10 Mark Glines wrote: > >> Integer is a good example of the problem, actually. >> >> The internal storage format doesn't change, > > It certainly can. I imagine that Kea-CL's Integers autopromote to BigInts (or > whatever the name is), and that might require a certain precision size. > >> but the methods you can call >> on it definitely will. HLLs wrap the Integer class with their own >> subclasses, so that they have methods they can call on integers, which >> are expected by the HLL. >> >> But when your perl6 function passes a Perl6Int to a TCL function, TCL >> HLL code code will try to access the integer, but it's not a TclInt, >> its a Perl6Int! The value itself is fine, but the methods it expects >> to find will not be there. Hence the need for conversion/mapping. > > Boundaries do have to be somewhat explicit; I agree. > > -- c >
Another interaction to consider: parrot version vs. HLL version (vs. other HLL version). We're going to need a standard way to identify the versions of the various compilers so we can say, in rakudo, "I need at least parrot 1.0 to run, and I want you to load version 8.5.3 of partcl.". We'll also need a way to have multiple versions of a single HLL installed simultaneously. -- Will "Coke" Coleda
