Dan Sugalski wrote:

At 10:49 AM +0200 10/18/02, Leopold Toetsch wrote:

In perl.perl6.internals, you wrote:

Do you have a more verbose description of variable/value separation?

Sure. Aggregates are a good one. For example, let's assume you have an array that can only hold real objects. The objects are the values, while the array itself is the variable. You *must* go through the variable's vtable to find a value, while when you manipulate the data you need to use the vtable in the value.

Actually, the new array code works already similar to this scheme. Actually - and WRT mulit_keyed ops - I would separate the variable access and the value access at the ops level:

Citing my "[RFC] 2. Proposal for _keyed" ops:


The 3 operand keyed add @a[$i] = @b[3] + %h{"k"}:

add_p_ki_p_kic_p_kc

(which we don't have)

would be 4 ops

key_p_p_ki [3]
key_p_p_kic
key_p_p_kc
add_p_p_p

The key_ ops get the variables out of the aggregate (by setting up pointers to the actual PMCs), while the add is manipulating the values. In above example, the variable fetch/store have it's own opcodes...


Tied data's another one. If you tie a scalar, the variable is tied not the value in the variable.

.... while with tieing, we need the variable fetch/store in the vtable.


struct {
    can;
    has;
    isa;
    union {
      scalar_vtable;
      aggregate_vtable;
      object_vtable;
    };
VTABLE;

Rather than a union, there'd be a set of pointers to various vtable pieces.

But a scalar (PerlInt) doesn't have all the _keyed methods. An aggregate doesn't need all the arithmetic or binary vtable entries. So IMHO the union would be a way to have smaller vtable pieces.

When e.g. a variable is tied, it's vtable would be replaced by a vtable, which does first fetch the variable, calls the tie-FETCH code, updates the variable and returns the value.


What I'd like to be able to do is, for variables that are effectively passive and don't actually have to get involved, to skip that extra level of indirection and promote the value's vtable functions into the variable's vtable.

So we would have e.g.:

- Plain scalar:
  vtable->var.get_integer => return cache.int_val
        ->val.get_integer => return cache.int_val

- Tied scalar:
  vtable->var.get_integer => call tie magic (updating the value) =>
        ->val.get_integer => return cache.int_val



leo



Reply via email to