Email list hosting service & mailing list manager

New draft (#2) and last call for comments on SRFI 217: Integer Sets Arthur A. Gleckler (31 Jan 2021 05:39 UTC)
Re: New draft (#2) and last call for comments on SRFI 217: Integer Sets Marc Nieper-Wißkirchen (31 Jan 2021 08:58 UTC)
Re: New draft (#2) and last call for comments on SRFI 217: Integer Sets Wolfgang Corcoran-Mathe (31 Jan 2021 19:19 UTC)
Re: New draft (#2) and last call for comments on SRFI 217: Integer Sets Wolfgang Corcoran-Mathe (03 Feb 2021 00:12 UTC)
Re: New draft (#2) and last call for comments on SRFI 217: Integer Sets Marc Nieper-Wißkirchen (03 Feb 2021 06:58 UTC)
Re: New draft (#2) and last call for comments on SRFI 217: Integer Sets Wolfgang Corcoran-Mathe (03 Feb 2021 07:25 UTC)
Re: New draft (#2) and last call for comments on SRFI 217: Integer Sets Marc Nieper-Wißkirchen (03 Feb 2021 07:30 UTC)

Re: New draft (#2) and last call for comments on SRFI 217: Integer Sets Wolfgang Corcoran-Mathe 31 Jan 2021 19:18 UTC

On 2021-01-31 09:27 -0800, Arthur A. Gleckler wrote:
> On Sun, Jan 31, 2021 at 12:58 AM Marc Nieper-Wißkirchen <
> xxxxxx@nieper-wisskirchen.de> wrote:
>
> > What happened to the XXX-search issue? I think the discussion about it is
> > still going on, isn't it?
>
> Based on his message from ten days ago and the diff of this draft, I
> thought that Wolfgang intended the addition of the separate updating and
> non-updating versions of iset-search to address the problem here.  Perhaps
> I misunderstood.

Apologies, yes, this is an outstanding issue; I haven't heard John's
opinion on this since before Marc's objection in
https://srfi-email.schemers.org/srfi-217/msg/15832456/  I haven't made
any change to iset-search(!)'s spec.  If John is still in favor of
rejecting different keys in the update continuation, I'll edit the
spec to reflect this; otherwise, no change is needed (Marc's solution).
I no longer have much of an opinion on this point, except that the
whole *-search thing is a bad design.

The separate, non-updating search procedure already exists, in fact
(iset-find).  Given this, and the plethora of updating procedures we
already have, my favorite solution to the "*-search issue" is to get
rid of this complex, too-clever form entirely, or, at least, to not
propagate it into new SRFIs.  In any case, I don't advocate adding any
more search/update procedures.  I hope I didn't create too much
confusion by bringing even more forms into the discussion.

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

"Optimization hinders evolution." --Alan J. Perlis