Two problems groping around in PerlHashes
Clinton A. Pierce
key exists in a PerlHash. Here's the kicker, I don't know what kind of
data's gonna be there: int, float, PMC, or string.
After hunting around in t/perlhash.t I found a few examples of checking for
keys that don't exist. They look like:
new P1, .PerlHash
set P0, P1["not_there"]
typeof S1, P0
eq S1, "PerlUndef", NOTTHEREBRANCH
Okay this is cool, except it doesn't work if the hash has mixed types in it
and the key you're looking for *actually exists*. For this code:
new P1, .PerlHash
set P1["mykey"], I0 # So it will exist
set P0, P1["mykey"]
Parrot correctly throws an error:
Cannot fetch PMC out of non-PMC key!
Correct or not, this is a pain in the butt. There's no way to grope around
in a PerlHash unless you already know what keys are there and what type
they are.
What I think we need is an exists opcode. And looking at
classes/perlhash.c it looks like there's a exists function already
there. I just can't figure out how to use it in PASM. There appears to be
no opcode for it.
Is this something of the PMC API we can expose to PASM programmers?
Can someone gimme a hint of how to make this a real live opcode? Or, if
someone can easily turn this on somehow, I think the best API for something
like exists would be:
exists Px[key], branch
So once I can tell the key is there, that brings up the second problem:
what exactly is behind that key? A PMC? A native type? The only thing I
can think of that would suffice would be to tinker with typeof to make it
able to recognize the PASM native types (N, I, S) and then to make it a
keyed op.
Leopold Toetsch
> While working on ...something... I found the need to be able to tell if
> a key exists in a PerlHash. Here's the kicker, I don't know what kind
> of data's gonna be there: int, float, PMC, or string.
[ snipp ]
> exists Px[key], branch
PDD02 specifies the needed methods
exists_keyed
type_keyed
perlhash/array have exists_keyed (but no type_keyed), though the opcodes
are missing.
> So once I can tell the key is there, that brings up the second problem:
> what exactly is behind that key? A PMC? A native type? The only thing
> I can think of that would suffice would be to tinker with typeof to make
> it able to recognize the PASM native types (N, I, S) and then to make it
> a keyed op.
We must define and standardize the enum_type_*. list.h has a bunch of
them, though, when reading PDD02, the values should be negative numbers
to discern these types from PMCs. hash.h has it's own types, which of
course should match those in list.h
leo
Jason Gloudon
> PDD02 specifies the needed methods
>
> exists_keyed
> type_keyed
The vtable PDD refers to type_keyed returning the type of the *PMC*. This
isn't accurate given the question. Should we change the PDD ?
> perlhash/array have exists_keyed (but no type_keyed), though the opcodes
> are missing.
On a tangent:
Shouldn't a Perl Hash be a homogenous data structure, ie. it should contain
just PMCs ?
--
Jason
Leopold Toetsch
> The vtable PDD refers to type_keyed returning the type of the *PMC*. This
> isn't accurate given the question. Should we change the PDD ?
As we are now (almost) able to generate packed arrays of chars, shorts
...., we should expand the type concept to not only the PMCs, but to all
types.
> Shouldn't a Perl Hash be a homogenous data structure, ie. it should contain
> just PMCs ?
The current HASH_ENTRY holding a UnionVal and a type is more flexible,
when native types are involved. So I'm not sure, if we should limit the
value to be PMC only.
And after recent discussions WRT C# and JVM, we'll have a bunch of yet
more native types in the future.
leo
Dan Sugalski
>Jason Gloudon wrote:
>
>>The vtable PDD refers to type_keyed returning the type of the *PMC*. This
>>isn't accurate given the question. Should we change the PDD ?
>
>
>As we are now (almost) able to generate packed arrays of chars,
>shorts ...., we should expand the type concept to not only the PMCs,
>but to all types.
Yep, I concur. Negative numbers for non-PMC types is fine.
>
>>Shouldn't a Perl Hash be a homogenous data structure, ie. it should contain
>>just PMCs ?
>
>
>The current HASH_ENTRY holding a UnionVal and a type is more
>flexible, when native types are involved. So I'm not sure, if we
>should limit the value to be PMC only.
For plain PerlHash PMCs, yes, they should be PMCs only. The union
went into them in a fit of enthusiasm and generality. :) More
specialized aggregates can hold more specialized things, but I'm not
sure we're going to have a need for something that really efficiently
holds multiple fundamental data types. All-ints, floats, strings, or
PMCs, sure, and certainly ones with tighter restrictions on what
types of PMCs can be stored, but I doubt we'll see a general need to
store, say, PMCs and ints.
>And after recent discussions WRT C# and JVM, we'll have a bunch of
>yet more native types in the future.
Yeah, I think so. I'm not thrilled with it, but that's rarely made a
difference in the past. Now shouldn't be any different.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> For plain PerlHash PMCs, yes, they should be PMCs only. The union went
> into them in a fit of enthusiasm and generality. :) More specialized
> aggregates can hold more specialized things, but I'm not sure we're
> going to have a need for something that really efficiently holds
> multiple fundamental data types. All-ints, floats, strings, or PMCs,
> sure, and certainly ones with tighter restrictions on what types of PMCs
> can be stored, but I doubt we'll see a general need to store, say, PMCs
> and ints.
Hash and arrays are diffent here, IMHO. An array either stores a PMC or
is an array of e.g. packed ints. Hash creation doesn't have a notation,
what will be stored in the hash finally. If a lot of plain int's are
stored in the hash, the current approach is faster, because there is no
need to generate a PMC for holding the value - though not so space
efficient.
So I'm not too sure, if we need two hashes, one for PMCs and a general one.
leo