Am Sa., 12. Juni 2021 um 18:44 Uhr schrieb Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>:
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.

Even if one has such a use case, the SRFI 1 form of unfold is certainly not the primitive one as your example in SRFI 224 shows.
 
In any case, this form is far better established than any variant, so
I'm not willing to remove it.

It doesn't need to be removed. But its presence should not forbid the existence of the more primitive CPS version.
 
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.

The efficiency improvements may be neglectable, but that has never been my main point.

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. 

Semantically, the Maybe versions are certainly less primitive. A tail call in Scheme is just a goto. And this is what we want to algorithmically express.

Wrapping everything in a Maybe just to decompose it, is a detour.
 
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.)

Using SRFI 157 is just one possibility. You can also guard against it in an implementation that guarantees eqv? equality of continuations one can get hold of through call/cc. (Chez Scheme is an example.)

By the way, this is a good example of why I have been claiming that R7RS-large is being devised in the wrong direction. We have been building the roof before the foundations are clear. At first, the core language semantics (including things like SRFI 157) should have been fixed, then the syntactic and lexical extensions (over R7RS-small) and, finally, the libraries built on top of the foundations.

Besides, as I wrote earlier, you can have the same non-tail-call-of-a-continuation-bug with your Maybe protocol. Just call just on a just before you return it.

Anyway, maybe R7RS-large is not the Scheme I am looking for. I'm attracted to Scheme because it does some things better than other languages and because it lets one write concise algorithms through which I can *exactly* express my intent.

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.

Have you thought about syntactic abstractions for all these procedures that hide the implementation details (CPS vs Maybe)?
-- Marc