Taylan Ulrich Bayırlı/Kammer scripsit:

> - A trivial change to the program input (say, one more or one less datum
>   to be inserted into a table) can overhaul the order in the table at a
>   point in the program where one of the whole-table operations is used.

Yes.

> - Same thing except with the code changing instead of the input.

Yes.

> - Using one of the whole-table operations, then a single delete
>   operation, then another whole-table operation, can give you totally
>   different orders in the two uses of the whole-table operation, because
>   a compaction happened in between.

Yes.

> - The last point combined with the other two points: on one run of your
>   program the two whole-table operations *do* have the same order, in
>   another run they don't.

I don't see that at all: if what your program does in the two runs is the
same, then the results out of the hash table will be the same, unless the
hash table implements salt (as discussed by Alex earlier).

> It really has good Heisenbug potential.  People should absolutely never
> rely on the order in any way if they want to make sure there's no loaded
> guns pointing at their feet.

I agree with that, but it's not because the result is non-deterministic,
it's because we can't readily predict it.  It's like relying on pseudo-random
numbers, which are just as deterministic.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
I don't know half of you half as well as I should like, and I like less
than half of you half as well as you deserve.  --Bilbo