Qua, 2008-07-23 às 00:09 -0700, chromatic escreveu: > 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 are two important aspects on this discussion: The first is that this collide with the "representation polymorphism" feature of Perl 6. You can only assume to know the internal representation (PMC with a Integer role) for native types. For a non-native type, I might have an ad-hoc object that answers true to .^does(Int), and the interpreter should behave accordingly. The second is that even if you solve that for Integer, how do you solve that for java.util.Vector, the Java List API (and all the implementations) and the Collection API (and all the implementations) (and all the other zillions of different APIs Java has)? Do you imply that you'll have to re-implement the Java core API in terms of PMCs? Even then, if some ad-hoc Java Class "implements java.util.Collection", how will you represent that in terms of a List PMC?... daniel
