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
(no sender)
(31 Jan 2021 08:58 UTC)
|
Re: New draft (#2) and last call for comments on SRFI 217: Integer Sets
Arthur A. Gleckler
(31 Jan 2021 17:27 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
(no sender)
(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
(no sender)
(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