Key question
Simon Glover
Or rather, a question about keys: what should the following two code
snippets do?
1) new P0, .Key
set P0, "1"
set N0, P0
print N0
end
2) new P0, .Key
set P0, "1"
set I0, P0
print I0
end
At the moment, the first one throws an exception ('Key not a number!'),
while the second one goes into an infinite loop and eventually
segfaults. As I see it, there are three possibilities:
i) In both cases, we throw an exception.
ii) We try to convert the string to an float (or int) using
string_to_num (or string_to_int). [In which case, what
do we do if the string is something like "asdf"?]
iii) We declare that trying to get numeric information out of
non-numeric keys is undefined behaviour, and so Parrot may do
anything (including segfault).
Which of these should Parrot do?
Simon
Leopold Toetsch
It's basically ii) C<key_integer> is missing the case of KEY_string_FLAG
so that recursively C<get_integer> is called on that key.
But we should generalize keys eventually. Keys can provide an index for
aggregates and allow chaining of indices for nested aggregates. Arrays
are simple: the key is an integer. But hashes currently don't support
non-string keys easily. We should be able to use arbitrary PMCs as
hash keys. The way to go here is to use the VTABLE_hash method to
generate an index aka hash value usable for accessing hashes.
A Key PMC can directly contain one of the Parrot native types I,N,S or
point to a PMC [1].
- the hashval of an Integer is the value
- the hashval of a Float should follow Python semantics. At least
hash(x.0) := hash(x) := x should be given.
- strings with a numerical value should probably hash to that number
- for PMCs the hash function should do the right thing. I.e. if the
PMC is a scalar one of the above rules should be used.
[1] This is currently broken.
> Simon
leo
Sam Ruby
>
> But we should generalize keys eventually. Keys can provide an index for
> aggregates and allow chaining of indices for nested aggregates. Arrays
> are simple: the key is an integer. But hashes currently don't support
> non-string keys easily. We should be able to use arbitrary PMCs as
> hash keys. The way to go here is to use the VTABLE_hash method to
> generate an index aka hash value usable for accessing hashes.
See: http://xrl.us/emnk
Except for fromkeys, get_string, and __new__, the logic is not Python
specific, and could easily be refactored into a common base class for
others to use.
- Sam Ruby
Leopold Toetsch
> See: http://xrl.us/emnk
=> dynclasses/pydic.pmc
> Except for fromkeys, get_string, and __new__, the logic is not Python
> specific, and could easily be refactored into a common base class for
> others to use.
Yep. The problem is that all current usage of hashes inside Parrot is
utilizing a STRING* key. OTOH HLLs are using PMCs in the normal case.
I've already proposed to get rid of the STRING* type. It's neither
low-level (there is no hardware CPU support for it like there is for
FLOATVAL) nor does a separate STRING type have any performance benefits.
Just the opposite - it leads to code duplication due to STRING and PMC
variants of opcodes and vtables.
sizeof(STRING) is 40 bytes (32-bit, optimized w/o C<version>). That's
exactly double the size of a PMC. Thus STRINGs are really big
structures. Wrapping them into a PMC for HLLs usage makes things just
worse.
By unifying STRING and PMC structures the hashing problem would just vanish.
> - Sam Ruby
leo