On Wed, Jul 23, 2008 at 3:09 AM, chromatic <[EMAIL PROTECTED]> wrote: > On Tuesday 22 July 2008 06:34:13 Moritz Lenz wrote: > >> There are actually many problems. For example, if a TCL function returns >> an integer, what will Perl 6 see? > > A PMC, which presumably performs the Integer role (in Parrot terms). If Tcl > on Parrot doesn't return this, Tcl on Parrot is wrong and bad. > > This is why we have PMCs and PMC roles (okay, why we will have PMC roles) and > especially why we have vtables.
There's more to PMCs than vtables. Is it reasonable for Tcl to always expect that a string-like vtable will provide a "get_list" METHOD? If not, how do we address that? What's the proper way to be able to add methods to objects in a way that works in a cross-HLL platform? There are vtables for some basic math, but how many HLLs are using the inc vtable when someone calls $a+1? Even simpler, the vtables obviously have different behaviors: Let's say someone passes a perl string into a tcl function that calls [expr $var++] and then proceeds to do some further usage of that value, knowing that it's obviously safe because if it wasn't an integer, it would have thrown an error on the ++. Except that because we're operating on someone else's PMC there, it -was- safe, so something blows up unexpectedly later. So, there's -some- language specific information in the PMCs. There's some in the compiler/interpreter. Where is the proper boundary? -Is- there a proper boundary? Basically, we need to declare what folks expect is going to happen in the cases where someone invokes things across HLL boundaries. If parrot's policy is "unless you do something stupid, it should work", then we need to write down what those stupid things are so that those of us implementing the HLLs can know to avoid them if we want to play nice. So, I'm curious: are METHODs in this category? I have functionality on Tcl's PMCs in METHODS that I require for proper operation. I don't check to see if the method exists before I invoke it. If it wasn't there, I'm not sure what my fallback would be. > If Tcl decides to reimplement its own data structures and not use vtables and > PMC roles in the same way as other languages, it will interoperate about as > well as the prototypical ugly American tourist complaining about Parisian > traffic on Bastille Day. Can you be more specific about how we could be using PMC roles to improve our HLL interoperability? SFAIK these are defined only in pmc2c POD with no actual code behind them. > I have trouble imagining that any other approach to interoperability works any > better (and devolves into lesser utter chaos -- maybe I can get a hotel named > after me for proving the existence of infinite forms of utter chaos). > > The fact that tie() works in Perl 5 suggests that this approach works in > practice. Where's the problem? > > -- c > -- Will "Coke" Coleda
