Am Di., 14. Sept. 2021 um 18:08 Uhr schrieb Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>:
On 2021-09-10 19:31 -0700, Arthur A. Gleckler wrote:
> On Thu, Sep 9, 2021 at 8:14 AM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>
> wrote:
>
> > Yes, 'ignore' is vestigial; thanks for pointing this out.  Perhaps
> > removing it could be errata-ed into SRFI 224.
> >
>
> If you'd like to make that change, would you please send me a patch or a
> pull request, and perhaps for the change John recommended below?:

With a little time to think about it, I'm not sure about removing the
'ignore' continuation from the -alter function.  I think it provides
a minor convenience, namely, it gives the caller a convenient way to
return the original dictionary if it's not otherwise bound.
e.g. using fxmapping-alter, for some fxm and function f:

    (fxmapping-search
     (f fxm)
     ...
     (lambda (insert ignore) (ignore)))

Without ignore, we'd have to write this in "A-normal form" so that
the modified dictionary can be returned:

    (let ((fxm* (f fxm)))
      (fxmapping-search
       fxm*
       ...
       (lambda (insert) fxm*)))

I don't see why the latter is less convenient than the former.  On the contrary, it is more explicit and easier to read.  And even if the former may be more convenient in some cases, it most cases where it is not needed, the baggage of an `ignore` argument has to be carried around while, in the latter form, one can simply drop the outer `let`.
 
(Of course, the same argument applies to the "found" case, where you'd
use the 'replace' continuation to get a copy of the original
dictionary; there's no ignore option.)

Indeed! If `ignore` is provided in the one case (for the reason you gave above - which still is not convincing to me), it should be provided in the other case (the found case) as well.  Using `replace` wouldn't be a good idiom.
 
I also think that the symmetry with the existing -search forms is
preferable,

-alter (or -find-change) is not -search (which should eventually be deprecated), so any symmetry may also mislead.
 
at least until/unless SRFI 225 specifies a new interface.
In any case, I don't think this is currently important enough to
warrant adding errata to SRFI 224.

At the moment, the issue is probably not pressing, but *eventually* SRFI 224 should be amended.  This should happen before it sees widespread use.
 
Thoughts?

See above. :)

-- Marc