One final issue (I hope): At the moment, the header file exposes an opaque struct Hamt and communication with the code happens through (stack-allocated) pointers to a Hamt. In the implementation, however, each Hamt just consists of two pointers (a pointer to a function table and a pointer to the root), so stack-allocating Hamts instead and passing them around by values makes as much sense.
This would have the advantage of reducing heap allocation. The disadvantage would be that adding further fields to a Hamt in future extensions might be more problematic and that identity of Hamts cannot be decided through pointer identity anymore (so the protocol how to decide whether an element has been inserted or not has to be changed). What do you think? Am So., 11. Okt. 2020 um 21:09 Uhr schrieb Bruno Haible <br...@clisp.org>: > OK for me. Thanks for having listened to the many remarks. Your remarks only helped to make the module better! Marc
