Hi Marc, > > How would a HAMT implementation look like that does not support persistence, > > but is instead optimized for destructive updates? Probably the reference > > counters would go away. Anything else? > > The reference counter would go away as would all tests for "shared" in the > code. > > Without a reference counter, an element can be any "void *" (instead > of a pointer to a struct starting with Hamt_entry), which is a > substantial change.
Thanks for explaining. > We can add a number of #if's to the code so that it either compiles to > an implementation of persistent or of transient hamts, but I wouldn't > rather do it right now because it would make the code harder to read. > But when the hamt code has become stable (and has been put to use and, > therefore, to real-world testing), this sounds like a feasible option. I agree that stabilizing the current code should come first. Then, whether the adaptations will be doable with a small set of #ifs or whether it will be best to copy the code, will remain to be seen. I mean, there are different red-black tree implementations in Gnulib and in the Linux kernel, and it does not cause maintenance problems because algorithmic code only very rarely needs updates. Bruno
