On 2020-12-08 21:18 +0100, Marc Nieper-Wißkirchen wrote:
> I haven't thought about it thoroughly yet (of course), but I'd say that a
> restriction for SRFI 146 that `new-key` compares equally (in the sense of
> the comparator) to `key` would have also made sense. Thus, for SRFI 217,
> which is only concerned with integers and for which different integers that
> compare equally (in the sense of eqv?) are not interesting, I see a point
> to drop the `new-key` argument to the `update` procedure.

Entirely agreed.  If `update' doesn't insert a new element and simply
returns the arbitray `obj' argument, though, a better name should be
chosen.  (`pass', perhaps.)  John?

I'm not familiar with the details of the RB and HAMT sample
implementations of SRFI 146, but it seems that mapping-search is
vulnerable to the problem I described.  hashmap-search is
"non-primitive" and doesn't seem to be affected.

> The philosophy behind `mapping-search` was that all other accessor and
> mutator procedures of SRFI 146 can be naturally implemented/defined in
> terms of `mapping-search`, making it the universal accessor/mutator
> procedure.

That's always been my impression; so much so that I wonder if this
procedure, with its two layers of continuation passing, should be
exported at all.  If <thing>-search(!) *is* used as the fundamental
traveral procedure, it's critical that we resolve the issue with
`update'.

Thanks very much for your input.

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

"[I]t is only a minor overstatement to say that [Brouwer] would have
thought twice about crossing a bridge if its engineers had used the
excluded middle to prove that it could bear his weight."
--Gilles Dowek