1) the PASM and PIR assemblers are now extended to understand arbitrary PMC constants:

 .const .Integer P0 = "42"       # PASM
 .const .Integer i = "42"        # PIR
 .const Integer  i = "42"        # PIR

Caveat: don't use this yet, the PMC constants vanish after the first GC sweep. See below.

The constant has to be a double-quoted string. E.g.

 .const FixedIntegerArray a = "[2,3,4]"

A PMC class that supports this feature has to implement:

- freeze/thaw for getting the value to/from bytecode
- the instantiate constructor, which is called with one STRING argument in S5 aka REG_STR(5) (see integer.pmc). It has to parse the string and create an appropriate PMC.


We already had this construct for subroutines:

  .const .Sub f = "foo"

which is actually:

  set_p_pc f, pmc_constant_of_sub_foo

2) as PMC constants should work from .PBC files too, PMC constants including subroutine PMCs are now serialized using the freeze/thaw mechanism.

3) TODO items:

I really want to have these constants live in the constant PMC pool. The constructor would then be a new VTABLE C<instantiate_constant> or some such. For now they are plain PMCs, but *not* marked during DOD, so don't use it for now. As a short-term solution we could of course scan the constant table and mark PMC items.

This also implies that attaching non-constant items to constant PMCs is illegal, e.g. setting properties on Sub PMCs. If you want to do this the PMC constant has to be cloned first.

Second: to protect these PMCs from any modification, a VTABLE variant should be swapped in that has all VTABLE slots that modify the PMC redirected to an error function:

  "Modification of a read-only value attempted at ..."

There is an experimental feature for such a scheme in the SArray PMC:

  pmclass SArray const_too ...
                 ^^^^^^^^^

This creates a second PMC class ConstSArray with a distinct type enum. But that's basically a bad hack, e.g. the type list in classes/pmc.num must contain an entry for that class too.

I'm not quite sure, if such read-only PMC variants should have a separate class type enum or just a different vtable.

We need this anyway for perl6:

  sub foo($a is ro, ...)

The PMC compiler already has a list of methods that modify the PMC, we just need a scheme to create these vtable variants in a more general way.

Comments, proposals, takers ;) welcome,
leo



Reply via email to