On Wed, 2008-07-23 at 10:11 -0400, Bob Rogers wrote: > True. But passing a Complex to any language that does not have a > concept of Complex is going to cause problems if the language tries to > treat it as anything but a black box. And a black box doesn't require a > special representation.
But we *do* need to have a defined way to pass black boxes back and forth, as when registering (and later calling) a cross-HLL callback with associated data. > But if you can't represent X in a language *at all*, what does it > mean to map such a thing? That's a good question. Does it throw an exception? Does it automatically become a black box? Does it convert to an opaque object with methods? Does it become a frozen data structure that the destination language just doesn't know how to thaw? Defining behavior for the exceptional cases must be part of our type mapping system. > 2. We may simply decide that when you pass containers between HLLs, > you explicitely give up some or all of the source language's > guarantees, and the source language compiler is required to treat > the data structure after that point as if it had been exposed to > hard radiation. > What guarantees? When you pass a hash to function that expects that arg > to be an array, strange things are bound to happen. And they are bound > to be equally strange regardless of whether the call to this function > was foreign or native. It seems strange to expect inter-language > calling to be somehow safer than intra-language calling. An inter-language call could be less safe or more safe, depending on implementation. If Parrot guarantees that a deep copy will happen, or that the structure passed is somehow guaranteed to be read-only, there may be less danger than even a native call. If Parrot *might* pass a writeable reference to the original structure, then the source language needs to treat an inter-HLL call as Tainting not just the structure contents, but the structure itself. -'f
