Re: fxmapping-unfold(-maybe) Wolfgang Corcoran-Mathe 12 Jun 2021 16:44 UTC

On 2021-06-11 22:36 +0200, Marc Nieper-Wißkirchen wrote:
> (X-unfold stop? mapper successor seed)?  Possibly so.  I think there
> > are cases in which the separate procedures are useful, but the
> > equivalent Maybe/CPS version is often more efficient, as the SRFI
> > notes.
> >
>
> Can you actually think of a case where separate procedures are useful and
> which cannot be easily mapped to the "new" unfold procedures?

Again, they are equivalent; I recall proving this in an exercise from
Jeremy Gibbons's lovely "Origami Programming", which refers to the
SRFI-1-style unfold as "convenient".  That's it's primary virtue that
I can see; if you have a predicate, mapper, and successor, you can
just "plug them in" without any lambda-wrapping.

In any case, this form is far better established than any variant, so
I'm not willing to remove it.

An attempt to wrap up the Maybe debate:

In efficiency terms, there are only two forms I'd change:
fxmapping-unfold-maybe and fxmapping-map-either.  These procedures
allocate n Maybe/Either values for an n-fxmapping argument, but use
those values entirely for an "internal protocol".  I'm open to CPSing
these designs.  As for the rest: stet.  Other procedures of SRFI 224
allocate at most one Maybe/Either value; this is trivial, in my
opinion.

I remain unconvinced of the "semantic" arguments against Maybe/Either.
I believe that these designs are easier to explain and to reason about
than their CPS counterparts.  I also consider the "non-tail-call of a
continuation" to be a source of difficult-to-trace bugs which we can't
easily guard against.  (Perhaps an implementation using SRFI 157 could
do this, but implementations of 157 are not yet commonly available.)

So, the potential revised versions of unfold-maybe and map-either.

We've already seen an example of the CPS unfold (which I've called
fxmapping-unfold* in the past, an obviously unsatisfactory name);
here's a sketch-example of the map-either form:

    ;; Fusion of map abs after partition negative.
    (fxmapping-map-split (lambda (k v insert-left insert-right)
                           (let ((u (abs v)))
                             (if (negative? v)
                                 (insert-left u)
                                 (insert-right u))))
                         fxmap)

This name (fxmapping-map-split) is also dubious, since SRFI 224
already has a fxmapping-split with different semantics.

So, if these procedures look good, we need better names.

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

"[F]ree flow of information is the only safeguard against tyranny.
... Beware of he who would deny you access to information, for in his
heart he dreams himself your master." --Commissioner Pravin Lal