Stéphane Payrard <[EMAIL PROTECTED]> wrote:

> The implementation of the methods key_* in keys.c imposed
> to the PMCs to be of type Key.  I don't' see the interest
> for atomic keys that could be mere PMCs.

> This concretely means that one can write the following and save a
> intermediate register:

>   P3 = PO[P1]

> instead of:

>   P3 = new P2, .Key
>   P2 = P1
>   P3 = PO[P1]

This doesn't parse ;) You mean something like:

    P2 = new Key
    assign P2, P1
    P3 = P0[P2]

or for short

    I0 = P1
    P3 = P0[I0]

> or instead of:

>   S0 = P1
>   P3 = P0[S0]  # if the key is used as a string

So both would be:

    P3 = PO[P1]

And that's the problem. An INT or STRING key has a definite type. A
plain (scalar) PMC doesn't have a type per se. You can extract a string
or and int out of a PerlInt or a PerlString and vv.

So the usage of the key isn't always clear. Sometimes the aggregate
might know, that it only takes INT keys (like Array). But what about
e.g. OrderedHash that takes both kind of keys and does different
things, depending on the key type? Or a Hash that takes int keys?

> Patch includes code and test.

Doesn't look bad though. But these kind of changes needs probably still
more thoughts and tests.

OTOH, we could use this idea, if we set the KEY_<type>_FLAG on
asingment to the PMC:

  new P1, PerlUndef
  P1 = 1        # has now KEY_integer_FLAG *and* is usable as a key for
  P3 = P0[P1]

or

  new P1, PerlUndef
  P1 = "key"    # has now KEY_string_FLAG *and* is usable as a key for
  P3 = P0[P1]   # P0 ias a hash-like thingy
  new P1, PerlUndef

and additionally:

  P1 = "42"
  set_key_type P1, .Key_integer_FLAG
  P3 = P0[P1]   # array access with integer key 42
  inc P1        # "43" ... still a string (BTW unimplemented inc ;)

This would need a little change (and slow down[1]) for key_next. But it
would make plain scalar PMCs as usable as keys as your patch does -
AFAIK for now :)

Your patch would slow down keyed access little, while above is more
general and with some extra cycles for setting the flag.

I can imagine, that this flags could also help Ponie to implement Sv?Ok
flags.

Comments?

leo

[1] check for non-NULL pmc->pmc_ext

Reply via email to