Re: fxmapping-unfold(-maybe)
Wolfgang Corcoran-Mathe 13 Jun 2021 19:19 UTC
On 2021-06-13 10:36 +0200, Marc Nieper-Wißkirchen wrote:
> What I don't get is your belief that Maybe is more familiar. This is
> certainly not true for Scheme programmers.
It depends if your "internal semantics" for algorithms has coproducts
or not, I suppose.
While I'm not sure I agree that the "certainly" is warranted,
there is obviously evidence for this claim: This is the first SRFI
(outside of 189, of course) to make any use of Maybe or Either.
> I agree that it doesn't make sense to add them just to SRFI 224. It would
> probably be a good idea to rethink it when more SRFIs are taken into
> account. Or SRFI 224 adds some of them, but then we should add them to the
> other SRFIs later as well.
Yes, let's come back to this topic at some point.
> 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 way I can code something like:
>
> ;; Moves the value at KEY, if it exists, to 0.
> (fxmapping-search fxmap key
> (lambda (insert ignore)
> (ignore))
> (lambda (v update remove)
> (fxmapping-adjoin (remove) 0 v))))
>
> With this obvious extension (which removes the need for any error checking
> wrt tail-calling!), the CPS version becomes much more expressive than the
> Maybe version.
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?
> Moreover, the old SRFI 146 version of the protocol needs the
> option to return an extra value (something that seems to be missing in SRFI
> 224 as well), but this we don't need here anymore because we can just use
> values to do it.
Yes, excellent. I thought the "obj" parameter of *-search was a
kludge, anyway; hence its absence from SRFI 224.
--
Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>
"Some folks think Postmodernism means little more than the Empowerment
of the Vulgar. Some folks think the same about Perl." --Larry Wall