| 4 | |
| 5 | Doing some more tests: |
| 6 | |
| 7 | 1. running the same script but with multiple calls to deserialization of the same file sometimes changes the order even within the same call of the script, but the amount of slots present is the same for each file. |
| 8 | |
| 9 | 2. running the same script but with multiple calls to hash-table->alist from the same deserialization always gives the same output (for that given deserialization). |
| 10 | |
| 11 | If I ran the script millions of times perhaps I'd see some swans of a different color, but from what I can see this tells me that the order of the slots can change during the deserialization, while the absense of slots is set in the serialization. |
| 12 | |
| 13 | I have a "ht" file (chicken-dump serialization.s11n > ht # on a run that didn't have (foo . bar)) and a "ht-foo-bar" file (chicken-dump serialization.s11n > ht # on a run that did). Looking at the difference between both files through a diff viewer like meld shows me that in the version of serialization.s11n that lost the (foo . bar), it *is* in there, it's just that those symbols are stored as back-references to **within** the hash-table. Remember that symbols share their data in memory, unlike strings. |