On 2021-06-13 21:39 +0200, Marc Nieper-Wißkirchen wrote:
> > > We could, actually, make the CPS protocol even more expressible and
> > useful
> > > by removing the restriction that update/remove/insert/ignore have to be
> > > tail-called. Just let them return the updated fxmapping and let the
> > > continuation of the call to success/failure to be the continuation of
> > > fxmapping-search.
> >
> > This does make a lot of sense to me, and I'd be more in favor of
> > CPS procedures if we could get rid of the tail-call requirement.
> > To express this, would it be sufficient to write, e.g. "invoking
> > ignore on no values returns a fxmapping ...", rather than the
> > old "... is expected to tail-call one of them ..." wording?
>
> For the functional update procedures, I think the change is as simple as
> this.

This works for the semantics of all of the CPS/Maybe procedures of
SRFI 224 except for fxmapping-unfold and fxmapping-map-either; with
these procedures, there are still continuations that must be
tail-called; they trigger the next step of the computation rather than
producing the final result.  e.g.  in

    (fxmapping-unfold*
     (lambda (seed stop insert&continue) ...)
     initial-seed)

it is meaningless (and thus unspecified or, possibly, an error) to
call `insert&continue' except in tail-context; `stop', on the other
hand, returns the new fxmapping, and so can be meaningfully called for
a value.  I'm not entirely satisfied with this, but it is confined to
these two procedures.

I'm willing to convert SRFI 224's Maybe-based forms to CPS if we can
just find good names for this second unfold and for
fxmapping-map-either.  (I don't want to foist Maybe on the Scheme
world, in any case.)  The only name for the CPS version of
fxmapping-unfold-maybe that I have so far is fxmapping-unfold*,
which is probably unwise.  For fxmapping-map-either, I considered
fxmapping-fork-map, which at least is less confusing than split-map
or partition-map.

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

"A LISP programmer knows the value of everything, but the cost
of nothing." --Alan J. Perlis