Simon Cozens <[EMAIL PROTECTED]> writes:
> > According to this document the set_p_n_i notation would be wrong. But
> > I already heard that the index-system is a moving target.
>
> In this case, I'd prefer you trusted the documentation. :)
Which one parrot_assembly.pod or core_ops.pod? They are both in docs
dir and state diffrent things. I selected the first one.
> > Anyway, I think a PMC-valued get/set-element method is necessary.
>
> Yes. Basically all the vtable methods would get an equivalent whereby
> each parameter is followed by a key of type KEY*.
KEY*? Isn't this just an array of all possible keys?
> > * Use special operation names for the indirect operations like
> > get_indirect and indirect_set and use the signature p_p_i for both
>
> I guess this.
you mean like this:
inline op indirect_set (out PMC, in PMC, in INT) {
KEY *key = $1->cache.struct_val;
KEY_PAIR *key_pair = key_element_i (key, $3);
$1->vtable->set_pmc_key ($1, $2, key_pair);
}
Or will the key system completely reengeniered?
I find it better to use vtable-functions like
unique PMC *get_pmc_index INTVAL index
unique void set_pmc_index PMC* value INTVAL index
and write in core.ops
inline op indirect_set (out PMC, in PMC, in INT) {
$1->vtable->set_pmc_index ($1, $2, $3);
}
With this system you are not nailed to the key is stored in
cache.struct_val and you can implement things like sparse arrays or
a packed bitarray or things like that.
> > * Use special assmbly-constructs for the optional key like
> > set PO[I1], P1 or P0;I1, P1
>
> How we disguise this in the assembler isn't really relevant.
Why not. The problem is how can the assembler know which vtable method
is to call.
My proposal was to use the order of the arguments to
distinguish indirect_set and get_indirect. This is much like the
indirect_set and get_indirect of floats or strings but uses a slightly
diffrent convention.
get_indirect_float: set (out NUM, in PMC, in INT)
indirect_set_float: set (out PMC, in NUM, in INT)
with pmc this would be identical. So I used this convention
get_indirect_pmc: set (out PMC, in PMC, in INT)
indirect_set_pmc: set (out PMC, in INT, in PMC)
the other ones can be easily adopted to this convention.
But the trouble begins if we would allow PMC as index-type.
The other ideas are use diffrent names for diffrent things (But then
this has to applied to floats, too) or use some magic markup.
Or where is the big diffrence I fail to see in getting a float or
getting a pmc out of an array.
> > * Introduce a new register-type for Keys.
>
> No, I don't think this is the right way.
I also have this feeling it isn't the right way.
We have already PMCs as general purpose objects, why introduce a new
special type.
bye
Jürgen
