On 2020-12-10 22:04 -0500, John Cowan wrote:
> On Thu, Dec 10, 2020 at 9:47 PM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>
> wrote:
>
> That's fine.  If `search' is set by convention, then this is, indeed,
> > an implementation issue.  I may have to fall back to the two-pass
> > search-then-adjoin approach, since I doubt there's a better way.
> >
>
> If the value searched for is the same (in the sense of eqv?) as the
> new-value passed to the update continuation, don't do anything: this case
> arises in "do nothing if the element is already present" cases.  If it is
> different, do a delete and an insert.  I can't see anything better than
> that.

Done.

> I haven't looked at the implementation: would it be more efficient to see
> whether the insert or the delete comes first, and then do the processing in
> that order?

There might be minor differences in efficiency in some cases, but the
asymptotic complexity of insert ∘ delete is the same as that of
delete ∘ insert.  So we'll stick with the former order for now.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"A picture is worth 10k words--but only those to describe the picture.
Hardly any sets of 10k words can be adequately described with pictures."
--Alan J. Perlis