Re: fxmapping-unfold(-maybe)
Wolfgang Corcoran-Mathe 14 Jun 2021 14:53 UTC
On 2021-06-14 10:23 +0200, Marc Nieper-Wißkirchen wrote:
> Am Mo., 14. Juni 2021 um 02:18 Uhr schrieb Wolfgang Corcoran-Mathe <
> xxxxxx@sigwinch.xyz>:
>
> > (fxmapping-unfold*
> > (lambda (seed stop insert&continue) ...)
> > initial-seed)
> >
>
> NB: SEED should come last to allow multiple seed values.
Yes. Thanks, good catch.
> > 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.
>
> To remedy the problem with fxmapping-unfold*, change the semantics of STOP.
> It shall abandon the current continuation and pass the resulting fxmapping
> to the continuation of the call to fxmapping-unfold*. Make INSERT&CONTINUE
> implicit by returning to the continuation of the call to the callback.
Ah, excellent. This is much simpler.
As a side note on naming, I think `fxmapping-accumulate' is a
good name; the only concern I have about it is that the very well-known
SICP used it to describe a fold procedure.
---
There is another issue I've found with replacing Maybe or the
"expected tail-call" semantics in fxmapping-update. Consider this
silly example:
(fxmapping-update key
fxmap
(lambda (k v replace delete) ; updater
(values 'deleted (delete))))
This must be valid if we state that invoking `delete' returns the
updated fxmapping. However, I believe that this constrains
fxmapping-update to calling the updater procedure in tail-context,
which may be inconvenient for some implementations (i.e. those
using structures which are naturally constructed via recursion).
This doesn't arise if we use required tail-calls or Maybe.
--
Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>
"A picture is worth 10k words--but only those to describe the picture.
Hardly any sets of 10k words can be adequately described with pictures."
--Alan J. Perlis