At 10:33 PM +0100 8/8/02, Tom Hughes wrote:
>In message <a05111b5bb9786eae041d@[63.120.19.221]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
>> At 6:58 PM +0100 8/8/02, Tom Hughes wrote:
>>
>> >Presumably with all keys being PMCs we will just encode the key
>> >arguments in the opcode name as a k, and kc for constant keys.
>>
>> Yep.
>>
>> >Likewise, the constant keys will presumably be encoded in the byte
>> >code much as specified in the PDD and then turned into PMC structures
>> >in the constant table when the byte code is loaded.
>>
>> Yep.
>
>One thing I just realised is that we still have a problem of how to
>tell what a P register used as an key means - it can either mean that
>the register contains a key, or that it contains an integer or string
>that is to be used as a key.
Nope. That's easy. P regs as keys mean they are real keys. Period.
Integer lookups need I registers, string lookups aren't done--they
need keys.
>If we're going to say that a P register is always taken to be a key
>then does that mean that you can't do this:
>
> set P0, "foo"
> set P2, P1[P0]
Right, you can't do that.
>Obviously that is manufactured, as you could do it with a constant
>index or an S register but in general terms if you have perl indexing
>an array or hash by a scalar then then it is likely to be indexing
>one PMC by another.
>
>If the above code was banned then you would have to build the key
>dynamically instead:
>
> new_key P0
> size_key P0, 1
> ke_set_value P0, 1, "foo"
> set P2, P1[P0]
Yup. or set the key value to be a PMC which you can then manipulate
outside the key struct. (Since we're just storing pointers, and thus
can twiddle things without having to store them back in things again)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
