Front page | perl.perl6.internals |
Postings from March 2006
Re: Value PMCs in Parrot?
Thread Previous
|
Thread Next
From:
Joshua Isom
Date:
March 11, 2006 17:55
Subject:
Re: Value PMCs in Parrot?
Message ID:
a5a277155671afdf8188cb051030fc64@ritalin.shout.net
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
>
Thread Previous
|
Thread Next