Nicholas Clark <[EMAIL PROTECTED]> wrote:
> http://opensource.fotango.com/software/ponie/plan
Wow, great detailed plan.
Some remarks:
1) objects seem to be missing
Parrot is much more object oriented then Perl5. The Perl5 "magic" that
depends on custom vtable is basically the task of creating a new class.
See below a rough Parrot program [1] that implements tie and overload
(somehow :)
For interoperbility I think that we need some more ParrotClass PMCs:
- the current is very similar to a perl5 blessed array, except it's
array size is fix
- a hash based one - similar to Python objects and of course Perl5
- scalar blessed can probably be done like below in [1]
- and eventually one that's based on a C structure, i.e. that abstracts
the {Un,}ManagedStruct PMCs.
2) a lot of Parrot (mostly) vtable methods are missing
We got tons of vtables and MMD methods with native types, but PMC
variants are missing. E.g. simple things like C<get_string> or
C<get_numeric> - we have a native C<get_string> which should be called
C<get_string_native>. Most of the string opcodes are just available as
native STRING variants too.
I've already proposed to split the vtable into various parts
("interfaces") so that not all PMCs take the penalty of having the full
vtable size all the time.
3) Parrot STRINGs
All the native types are mostly unusable for Perl5, Python,.... Only
Perl6 has a notion for native types. A String PMC is just a wrapper
around such a STRING PObj and adds one indirection to all string access,
that's not good.
OTOH a STRING is not a lightweight or thin structure, just the opposite
of it, its' much bigger then a PMC. The discussion "String theory" on p6l
has shown that Perl6 has a more low-level concept of the C<str> native
type - more something like a plain C string, w/o unicode support.
STRINGs are unusable with multi-threaded Parrot as the String PMC has to
properly lock the STRING, the STRING itself can't do that.
This leads directly to:
4) PMC structure
PMCs are too rigid: Either too big (e.g. Integer) or too small for more
complex types like subroutines or aggregates. The fixed size restriction
either forces wastage of space or additional indirections. I'd like to
have a PMC layout that's much more the layout of Perl5: a fixed and
possibly small header and, if upgraded, an additional body.
This means (current STRING + vtable) := String PMC.
5) dunno, but switching lexicals to Parrot seems to be late in the plan.
Needs IMHO be done, when running Parrot opcodes.
> Nicholas Clark
leo
[1]
$ cat tie.imc
.sub main @MAIN
.local pmc d, l, r, cl, _add
cl = subclass "Integer", "AInt"
d = new "AInt"
l = new "AInt"
r = new "AInt"
l = 3
r = 39
print l
print "\n"
print r
print "\n"
add d, l, r
print d
print "\n"
_add = find_global "AInt", "__add"
$I0 = typeof cl
.include "mmd.pasm"
mmdvtregister .MMD_ADD, $I0, $I0, _add
l = r + d
print d
print "\n"
.end
.namespace ["AInt"]
.sub __add # @MULTI(AInt, Aint) - not yet
.param pmc l
.param pmc r
.param pmc d
print "in add\n"
$I0 = l
$I1 = r
$I2 = $I0 + $I1
d = $I2
.end
.sub __get_integer method # __get_numeric
print "FETCH\n"
$P0 = getattribute self, "AInt\0__value"
$I0 = $P0
.return ($I0)
.end
.sub __set_integer_native method # __set_integer
.param int v
print "STORE\n"
$P0 = getattribute self, "AInt\0__value"
$P0 = v
.return ($I0)
.end
$ ./parrot tie.imc
STORE
STORE
3
39
42
in add
FETCH
FETCH
STORE
42
