If the compiler goes through all the constants at compile time to find
identical ones, why not use ".const float number = 0.0"? With pmc's,
only .Sub is supported I think. But for more complex types, the best I
can think of is being able to freeze a pmc and store it into the const
table, such as in an :immediate sub just without running the opcodes
after compile time. I don't think it's possible to freeze a pmc into
the pbc, right now.
On Mar 11, 2006, at 12:35 PM, Audrey Tang wrote:
With Leo's help, I'm porting Pugs's native PIL VM to Parrot (HLL
"Perl6"
under "pugs_group"), and we immediately stuck on translating the notion
of a "value object" to Parrot.
First, some backgrounds from Perl 6's class hierarchy. There are three
kinds of classes in Perl 6:
"Native" classes: bit, int, buf, str, num, complex...
"Value" classes: Undef, Ref, List, Bit, Int, Str, ...
"Container" classes: Scalar, Array, Hash, ...
Container classes are naturally PMCs.
We can map "int", "str" and "num" to registers, and "bit"/"buf"
can be emulated by "int"/"str" registers. However, for "complex" we
need either multiple registers, or (easier) always use a boxed Value
class.
Unfortunately, Parrot has no natural way to represent Values. In Perl
5,
it's modelled as a "const" SV* with SVf_READONLY set:
$ perl -e 'for (1) { $_++ }'
Modification of a read-only value attempted at -e line 1.
Currently, the only way to mark a PMC as a "Value" PMC is to derive
from
the mutable "scalar" interface first, and then manually disable all the
vmethods marked as "mutable" (e.g. "increment"). If we don't do this,
bizarre things like $_++ above can occur without checking.
Moreover, because Value PMCs never change their content, they can be
shared for autoboxing purposes (i.e. if I0 and I1 contains the same
integer, they box into the same PMC), as well as for other various
purposes, which may affect GC as well.
The easy workaround for now is to have a "does readonly" interface in
addition to the current "does scalar", which forbids all self-mutable
vmethods.
I don't know whether it makes sense to mark value-ness and use them
elsewhere -- certainly a too-drastic way is to have V* registers that
affects GC -- but at least I'd like a way for "1.id == 1.id" to work
reliably in the future.
Thanks,
Audrey
