iset-search implementations Wolfgang Corcoran-Mathe 08 Dec 2020 20:00 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 08 Dec 2020 20:18 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 09 Dec 2020 18:07 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 10 Dec 2020 12:00 UTC
Re: iset-search implementations Arthur A. Gleckler 10 Dec 2020 16:40 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 10 Dec 2020 16:50 UTC
Re: iset-search implementations Arthur A. Gleckler 10 Dec 2020 16:51 UTC
Re: iset-search implementations John Cowan 11 Dec 2020 02:23 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 11 Dec 2020 02:47 UTC
Re: iset-search implementations John Cowan 11 Dec 2020 03:04 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 11 Dec 2020 18:41 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 12 Dec 2020 10:59 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 14 Dec 2020 17:44 UTC
Re: iset-search implementations John Cowan 16 Dec 2020 15:34 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 16 Dec 2020 15:42 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 31 Dec 2020 18:23 UTC
Re: iset-search implementations John Cowan 07 Jan 2021 21:42 UTC
Re: iset-search implementations Arthur A. Gleckler 08 Jan 2021 04:39 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 08 Jan 2021 13:31 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 08 Jan 2021 23:47 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 09 Jan 2021 13:28 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 10 Jan 2021 23:35 UTC
Re: iset-search implementations Arthur A. Gleckler 11 Jan 2021 00:04 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 11 Jan 2021 06:33 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 11 Jan 2021 00:27 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 12 Jan 2021 14:34 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 12 Jan 2021 18:55 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 18 Jan 2021 09:13 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 19 Jan 2021 18:54 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 20 Jan 2021 10:53 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 21 Jan 2021 20:31 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 11 Dec 2020 08:40 UTC

Re: iset-search implementations Marc Nieper-Wißkirchen 10 Dec 2020 12:00 UTC

Am Mi., 9. Dez. 2020 um 19:07 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:

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

The name `update` is not exposed in the API but just used in the
documentation so the choice of the name is not very important.

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

Indeed, `mapping-search` is affected because I never thought about
using a non-equivalent `new-key` when I wrote that code. Of course, it
can be fixed by special-casing that case, but it would be better to
add an erratum to SRFI 146 saying that `new-key` has to be equivalent
to `key` in the sense of the comparator. This is what has always been
the intended use anyway.

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

I have used `mapping-search` on some occasions in private code when
the simpler procedures weren't enough. So it is definitely worth to be
exported. (I think it also fits quite well the idea of Scheme to
provide powerful primitives.) But I agree that the spec needs to be
fixed.

Marc