Le Mon, Feb 09, 2004 at 09:52:28PM +0100, le valeureux mongueur Leopold Toetsch a dit:
> 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]
Yes, sorry, I have trouble (among other things) to go from IMC syntax
and back to PASM. One of my points is that one should not create a key or
do an explicit intermediate operation if he wants to use a regular pmc
as a key.
>
> 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?
It is up to the accessed pmc to decide what to do with the subscript.
On the other hand, in some cases, it does need some extra information.
Because the type of the pmc or of its value may not help.
Example : two-way hashes (supposing that keys and values are one to
one).
In keeping with the spirit of Perl, I propose setting the flag in
the subscript pmc in the access operation by adding some syntax to
imcc:
P3 = PO[P1] # regular keyed access without flag
# set a flag in P1 before doing the equivalent of C<P3 = PO[P1]>
P3 = P0{P1}
The C<get_*_key()> would test the flag to do the proper operation.
To compare it with your proposition below: even if the flag lies in
the subscript pmc, I think it is more a property of the operation than
of the subscript pmc. It does not specify the type of a value. That's
why I want to bundle the flag setting with the access operation.
Anyway, a flag avoids to create a new set of keyed methods.
My scheme needs new syntax to specify to the accessed pmc what is the
required operation, but it is familiar to Perl programmers and avoids
to learn yet another assembler statement, the explicit setting of the
flag. I agree that the explicit flag setting is still a progress
because it does not need a extra register (like the creation of an
explicit Key did).
>
> > 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.
Anyway, with the flag (your scheme or mine), we save a register
which is a very scarce ressource.
>
> 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
--
stef
