I am going to implement the following iterator API as well:
/* An alternative interface to iterating through the entry of a hamt
that does not make use of a higher-order function like
hamt_do_while uses the opaque Hamt_iterator type. */
typedef struct hamt_iterator Hamt_iterator;
/* Return a newly created iterator for HAMT. */
extern Hamt_iterator *hamt_iterator_create (const Hamt *hamt);
/* Free the iterator ITER created through hamt_iterator_create or
hamt_iterator_copy. */
extern void hamt_iterator_free (Hamt_iterator *iter);
/* Return an independent copy of ITER that is initially in the same
state. */
extern Hamt_iterator *hamt_iterator_copy (Hamt_iterator *iter);
/* Return true if ITER is not at the end, place the current element in
*ELT_PTR and move the iterator forward. Otherwise, return
*false. */
extern bool hamt_iterator_next (Hamt_iterator *iter,
Hamt_entry *const *elt_ptr);
Am So., 11. Okt. 2020 um 10:20 Uhr schrieb Marc Nieper-Wißkirchen
<marc.nieper+...@gmail.com>:
> Am So., 11. Okt. 2020 um 03:28 Uhr schrieb Bruno Haible <br...@clisp.org>:
> > - Creating a closure in C (unlike Scheme or Lisp) is tedious
> > hand-work.
> > (The GNU C extension that allows local functions inside functions
> > [1]
> > is not a solution, because
> > - it is unportable,
> > - it forces an executable stack on many platforms, which is
> > considered bad for security.)
PS Conceptually, hamt_do_while takes a closure, which consists of the
function pointer PROC and the closure environment DATA.
If this interface is sufficient for an application, it is more
lightweight than the alternative interface above because all
intermediate state is stored on the stack.
