Re: First victim, er SV type

On Fri, May 07, 2004 at 01:50:32PM +0100, Nicholas Clark wrote:
(lots of stuff about morphing SVs into PMCs).

When I read this, and started to try and think about it and understand it,
I realised that my current mental picture of Ponie wasn't good enough to
be able to reply meaningfully. So if I might be permitted, I'd like to
digress for a moment with some questions - not just addressed to Nick, but
to the whole list.

My understanding is that in Perl5, "ops are smart, SVs are dumb", while
in Perl6/Parrot, it's the reverse: "bytecode is dumb, PMCs are smart".
For example in Perl5, an SV is really little more than a storage vessel
that can hold various items of data such as an IV, an NV or a string,
plus some flags that indiciate what's stored in it. On the other hand,
the Perl5 'int' opcode 'knows' about all the possible things that could be
stored in an SV, and has full responsibility for doing all the work
involved in coercing the SV's value into an integer (such as converting a
string into an int, or using the address of of the thing pointed to by an
RV as as int). With parrot, the 'int' byte code just calls the get_int method
on the PMC, and the PMC holds all the intelligence as to how to extract an
integer value out of itself.  Actually I'm oversimplifiying slightly,
since SVs can have magic attached, which is a half-assed attempt to make
them intelligent like PMCs.

Anyway - what, philosophically speaking, is Ponie's intentions in this
area? Does it just want to use PMCs as dumb storable vessels, or does it
want to transfer the intelligence into them? And are we intending to use
off-the-shelf parrot/Perl6 PMCs, or a whole bunch of Ponie-specific PMCs
that ape all the Perl5 SV types?

Also, what actually is the final purpose of Ponie? Is it intended to be
an integrated part of Perl6+Parrot, so that when someone compiles a Perl
program, the parts of it that are Perl5 syntax get compiled using a bunch
of Perl5 byte codes, but apart from that its one big happy executable,
with perl5 bits of code calling into perl6 bits of code and vice-versa,
with PMCs being happily passed between them? And running as least as fast
as the current Perl 5 interpreter? Or is the goal less ambitious?

Dave.

-- 
In my day, we used to edit the inodes by hand.  With magnets.