Am So., 11. Okt. 2020 um 13:56 Uhr schrieb Bruno Haible <br...@clisp.org>: > > Marc Nieper-Wißkirchen wrote: > > I am not so convinced of whether it makes sense to create a > > gl_set/gl_map frontend for this hamt implementation. > > Wikipedia [1] lists some advantages of HAMTs even without the persistence. > > > It is optimized > > for the persistence (otherwise, use ordinary hash tables), while the > > gl_set/gl_map interface is for destructive updates. > > 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. 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.
