bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Bruno Haible <bruno@clisp.org>
To: "Marc Nieper-Wißkirchen" <marc.nieper+gnu@gmail.com>
Cc: bug-gnulib@gnu.org
Subject: Re: Node to first or last element of a sequential list in module list/xlist
Date: Mon, 05 Apr 2021 01:30:41 +0200	[thread overview]
Message-ID: <2792583.fiM0EhyeSA@omega> (raw)
In-Reply-To: <CAEYrNrTatLc1QcBPzhbs9b64Dv5P5J7HuR+Tj8o6QKh91u1jZw@mail.gmail.com>

[Adding back bug-gnulib in CC.]

Hi Marc,

> > Yes, some algorithms need a second, temporary list. Not all algorithms
> > can be written to use the original list, be efficient in O() terms, and
> > be implementation-independent.
> >
> 
> Is there a fundamental reason why a list walking algorithm that both
> inserts and removes items is not possible with an arbitrary Gnulib list
> container? Obviously, the current API doesn't allow it. If it is just the
> limitation of an API that forces one to work with a second, temporary list,
> 
> Would it be possible for all list types to provide a
> 
> gl_list_node_t gl_list_remove_node_then (gl_list_t list, gl_list_node_t
> node, gl_list_node_t then)
> 
> that removes NODE from LIST and returns the node of that element
> represented by THEN before the removal.  The precondition is, of course,
> that THEN != NODE.  Furthermore, if THEN is NULL, NULL is returned.
> 
> A typical pattern would be:
> 
> for (gl_list_node_t i = gl_list_first_node (list); i != NULL;)
>   {
>     Fruit fruit;
>     if (is_apple (fruit))
>       node = gl_list_next_node (list, gl_list_next_node (list,
> gl_list_add_before (list, node, make_pear ())));
>     else if (is_peach (fruit))
>       node = gl_list_next_node (gl_list_add_after (list, node,
> make_strawberry ()));
>     else if (is_banana (fruit))
>       node = gl_list_remove_node_then (list, node, gl_list_next_node
> (list));
>   }
> (This is just a silly example for an algorithm that may want to replace
> elements by sublists (including sublists of length 0).)

This example makes it clear what you mean.

And what if the programmer wants to preserve not one 'then' node, but
several at once? One could generalize the function to

  void gl_list_remove_preserving_nodes (gl_list_t list, gl_list_node_t victim,
                                        size_t count, gl_list_node_t *to_preserve);

which would preserve the nodes to_preserve[0 .. count-1].

But for my feeling, programmers will not want to code like this. It is
so much easier to allocate a new list and destroy the old one afterwards.

Bruno



  parent reply	other threads:[~2021-04-05  2:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-02 15:52 Node to first or last element of a sequential list in module list/xlist Marc Nieper-Wißkirchen
2021-04-02 22:49 ` Bruno Haible
2021-04-03  7:03   ` Marc Nieper-Wißkirchen
2021-04-03  9:49     ` Bruno Haible
2021-04-03 10:00       ` Marc Nieper-Wißkirchen
2021-04-03 10:14         ` Bruno Haible
2021-04-03 10:26           ` Marc Nieper-Wißkirchen
2021-04-03 16:28             ` Bruno Haible
2021-04-03 16:46               ` Marc Nieper-Wißkirchen
2021-04-03 16:55                 ` Bruno Haible
     [not found]               ` <CAEYrNrTatLc1QcBPzhbs9b64Dv5P5J7HuR+Tj8o6QKh91u1jZw@mail.gmail.com>
2021-04-04 23:30                 ` Bruno Haible [this message]
2021-04-05 10:20                   ` Marc Nieper-Wißkirchen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2792583.fiM0EhyeSA@omega \
    --to=bruno@clisp.org \
    --cc=bug-gnulib@gnu.org \
    --cc=marc.nieper+gnu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).