Key question

[Klaas-Jan Stol]

Hi,

currently I'm experimenting a bit with Keys. It seems that a Key *can* 
be set to a number (floating point), but that this results in a 
segfault, when using that key.


So:

.sub main
   P0 = new .Key
   P1 = new .Hash
   P2 = new .Integer
   # set the key to a number
   P0 = 1.23
   P2 = 42
   P1[P0] = P2
   end
.end

does not work. Is this behaviour to be expected (it's supposed not to 
work), or is this just not implemented yet (it will work in the future)?


Thanks,
klaas-jan

Re: Key question

[Leopold Toetsch]

Sam Ruby [EMAIL PROTECTED] wrote:

 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 Cversion). 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

Re: Key question

[Leopold Toetsch]

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) Ckey_integer is missing the case of KEY_string_FLAG
so that recursively Cget_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

Re: Key question

[Sam Ruby]

Leopold Toetsch wrote:
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

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