Re: Non-opaque hamt type?

["Marc Nieper-Wißkirchen" <marc.nieper+gnu@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3308 bytes --]

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
> >
>

[-- Attachment #2: Type: text/html, Size: 4998 bytes --]