On Wed, Jul 23, 2008 at 10:04 AM, Will Coleda <[EMAIL PROTECTED]> wrote: > 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.
One more slightly complicated example. Tcl has two different hash-like values. One is manipulated using [dict] and friends, and can have nested dictionaries, and is representable as a string. The other is manipulated using [array] and friends, can only have a single top level set of keys, and cannot be represented as a string. Both are delcared as being Hash-y in their PMC declaration. But in this case, a lot of the functionality for dealing with them is in the commands themselves because of the language. In this case parrot's set of roles is insufficient for me to make a determination as to which type I might conceivable want to pass into another HLL (Takes a hash? ok, have a TclArray!), and if I get something Hash-like and someone tries to use 'array' on it... do we have any reasonable expectations of what should happen? What if someone passes me a perl Hash to something that tries to call Array? Right now I explicitly check the type of the PMC to verify I can work on it. This isn't really a portable way to do this, but what is? Part of our problem is that HLL interaction doesn't really work for anyone at the moment, so we can't write you a test case that blows up and say "here, fix this or tell us why." > 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 > -- Will "Coke" Coleda
