On Thu, Jan 30, 2003 at 11:41:04AM -0500, Aaron Sherman wrote: > On Wed, 2003-01-29 at 16:41, Nicholas Clark wrote: > > > And the demonstration was as expected? > > Yes, of course. If you modify a hash, or look at another hash, you > should not expect the same results. Why would you? More importantly, why > would the conversation threat up until now lead to such an example?
Nothing explicit. But no-one had not said that hash ordering was the function of something deterministic based on hash keys. ie it was possible to read the thread and assume that for a hash with a given set of keys, one particular implementation would only return the keys in one implementation defined way. Some of the behaviour I demonstrated wasn't actually what I expected, but thinking about it based on how perl5 does hashes it makes sense. Now it's explicit, which hopefully is clear. I know I surprised at least one knowledgeable reader of the list with the demonstration. On Thu, Jan 30, 2003 at 11:41:30AM -0500, Aaron Sherman wrote: > They guarantee (as stated in the docs for keys, in the perlfunc manpage, > go check it out) that keys, each and values will return the elements of > the hash in the same order as each other as long as you don't modify the > hash between calls. > > If Parrot calls rand on the sequencing of returned hash data, that's > fine as long as it saves that seed until the hash is later updated.... I think all that Dan will want parrot to guarantee is that if you iterate completely without modifying the hash, you will get all the elements out exactly once. But parrot is also designed to remove the speed hit of tie, so if your program needs more predictable hash ordering semantics, it is intended that it be easy *and efficient* to let a custom hash do this. Possibly even a "custom" hash supplied in the core libraries. I am arm waving, but it's extrapolation from what I know the design goals are. It could be that parrot would be allowed to run under a use less 'memory' and have GC shrink hashes were possible. In fact, there's nothing stopping anyone implementing a use less 'memory' for 5.10 that causes such behaviour. Nicholas Clark
