Simon Glover <[EMAIL PROTECTED]> wrote:
> 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).
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
