Re: Non-opaque hamt type?

[Marc Nieper-Wißkirchen]

Please excuse the delay in finalizing the new module. I was distracted due to the start of the semester in October last year and then forgot to finish my work.

To summarize, I have finally come to the conclusion not to change the API as theorized in this thread.

First of all, the benefits of making the hamt type non-opaque are too small compared with the possible drawbacks (the non-opaqueness, the inability to return NULL in future API extensions, etc.).

Secondly, after having given it some more thought, the alternative protocol (which we have called more robust) seems to be harder to understand because "p != e" could then mean two different things. So I will leave the original protocol in place, which is easy to comprehend: If "old_hamt == new_hamt", no insertion has taken place and one has manually free the element one has attempted to insert. If "old_hamt != new_hamt" the element has been inserted and has now to eventually free "new_hamt" besides "old_hamt".

After I have rebased my code to HEAD, I will commit the new module to Gnulib.

Thank you for your patience.

Marc

Am So., 18. Okt. 2020 um 20:11 Uhr schrieb Marc Nieper-Wißkirchen <marc.nieper+gnu@gmail.com>:

Okay, if you find the latter protocol better anyway, I will switch to
this protocol, and hamts will be stack-allocated (just two words) and
passed by value.

Thanks,

Marc

Am So., 18. Okt. 2020 um 19:58 Uhr schrieb Bruno Haible <bruno@clisp.org>:
>
> Marc Nieper-Wißkirchen wrote:
> > The existing protocol is as follows:
> >
> > Hamt_entry *e = hamt_entry (...);
> > Hamt_entry *p = e;
> > Hamt *new_hamt = hamt_insert (old_hamt, &p);
> > if (old_hamt == new_hamt)
> >   {
> >     /* The element hasn't been insert as an equivalent element has already been in the hamt. p now holds a reference to the entry that already existed in the hamt.
> >     element_free (e);
> >     ...
> >     hamt_free (old_hamt); /* We don't have to free new_hamt because no new hamt was created. */
> >   }
> > else
> >   {
> >     /* The element has been inserted. p hasn't changed. */
> >     ...
> >     hamt_free (old_hamt);  /* This frees all hamts */
> >     hamt_free (new_hamt); /* and all elements inserted, including e. */
> >   }
> >
> > A protocol where no pointer values need to be compared could use p to
> > carry the information:
> >
> > Hamt_entry *e = hamt_entry ();
> > Hamt_entry *p = e;
> > Hamt new_hamt = hamt_insert (old_hamt, &p);
> > if (p == e)
> >   {
> >     /* The element has been inserted. */
> >     ... /* See above. */
> >   }
> > else if (p == NULL)
> >   {
> >     /* The element e already existed in the hamt. */
> >    ... /* See above. */
> >   }
> > else /* p != e && p != NULL */
> >   {
> >     /* An element equivalent to e already existed in the hamt. p now holds this element. */
> >     ... /* See above. */
> >   }
>
> I find the latter protocol more robust: it does not depend on details of
> the implementation of hamt_insert.
>
> Can you decide on your original question (allow stack-allocated HAMTs)?
> I don't feel I can help you decide this.
>
> Bruno
>