On 2021-06-12 22:07 +0200, Marc Nieper-Wißkirchen wrote:
> No need to apologize. I just may have failed to articulate my argument well
> enough. In any case, thank you for considering my arguments and offering me
> counter-arguments so that the best solution (whatever it will be) has a
> chance to arise.

Thank you for sharing your thoughts!

> > Designs using Maybe *or* continuation passing are both "low-level", in
> > the sense that we have to pay attention to the book-keeping details of
> > how choices are made.  If CPS has an advantage over Maybe, it is
> > because it is the "more primitive" approach in Scheme.  The goal here,
> > however, is to provide procedures which high-level syntactic
> > abstractions can be expressed in terms of.
> >
>
> I am not sure what the last "however" refers to.

What I mean here is, I think, what you refer to in your
"`if' vs. `whensoever'" example.  One might forget the procedural
language entirely and specify a number of macros for working with
fxmappings, much as an `if' form makes sense without an underlying
procedure.

> A major goal should certainly be to be able to express algorithmic content
> as directly as possible. Some programming languages make it easier than
> others. For example, when coding an algorithm that returns two values, I
> can do this directly in Scheme, namely by, well, returning two values. In a
> programming language that does not have multiple values, I cannot express
> the algorithmic intent as directly because I have to wrap the values in
> some kind of struct, which I then return.

I think this comes down to how we express algorithms.  If we think of
a partial function (say `fxmapping-lookup') as "returning some values,
or ⊥", then Maybe is, I think, the most direct expression.  If we
rather talk in terms of delivering values to continuations, as
R[67]RS often does, then CPS is more expressive.  I argue that the
latter is generally more familiar and convenient, but I'm confident
that this is a matter of taste.

There is also the (justly unpopular) argument of popularity.
Maybe/Option is well-established in the functional language world,
outside of the Lisps.  Arguments for CPS over Maybe in the
ML-descended world seem to be few and far between; it seems to be a
familiar and expressive-enough way to describe partial functions for
those communities.

> In view of this, it may arise an easier usable API when thin syntactic
> abstractions over some procedures are provided instead of the procedures
> themselves. Another possible advantage would be that they can render the
> question of CPS vs Maybe moot.

Do any useful syntactic abstractions for SRFI 224 operations come to
mind?  I can't find any in the related "dictionary type" SRFIs, and
I'm concerned about adding entirely new forms at this point.

In any case, I do want to provide an expressive procedural interface,
not one that is difficult to use without additional syntax.

> PS Part of my problem is that I don't think I have seen a compelling
> example for why the CPS convention produces code that would be harder to
> understand.

I believe the specs of fxmapping-alter and fxmapping-search are
a good example.  (Although someone could probably express both more
concisely than I have.)

(fxmapping-alter fxmap k proc) → fxmapping

proc is a procedure of type maybe[exact-integer, *] → maybe[*].

Returns an fxmapping with the same associations as fxmap, except that
the association, or lack thereof, for k is updated as follows.  If the
association (k, v) exists in fxmap, then proc is called on Just k v;
if no such association exists, then proc is called on Nothing.  If the
result of this application is Nothing, the association is deleted (or
no new association is added); if the result is Just v′, the
association (k, v′) is added to the resulting fxmapping, replacing any
old association for k.

;;;; vs.

(fxmapping-search fxmap k failure success) → fxmapping

Returns a new fxmapping with the same associations as fxmap, except
that the association with key k (or the absence thereof) is updated as
follows.

* If fxmap contains an association (k, v), then success is invoked on v
and two procedure arguments, update and remove, and is expected to
tail-call one of them.

  + If update is invoked on an arbitrary value v′, then the resulting
    fxmapping contains the association (k, v′), which replaces the old
    association for k.

  + If remove is invoked on no arguments, then no association for k
    appears in the resulting fxmapping.

* If fxmap does not contain an association for k, then failure is
  invoked on two procedure arguments, insert and ignore, and is
  expected to tail-call one of them.

    + If insert is invoked on an arbitrary value v, then the resulting
      fxmapping contains the association (k, v).

    + If ignore is invoked on no arguments, then no association is
      added and the resulting fxmapping is identical to fxmap.

The result of calling any of the update, remove, insert, and ignore
procedures in a non-tail context is unspecified.

---------

I suggest that fxmapping-alter is more concise and probably clearer to
those unfamiliar with CPS.  There's also the fact that the procedure
object passed to fxmapping-alter is an operator on Maybes; it simply
has to return a value, and so might just be some arbitrary operator
you've written.  This is a major win for compositionality.  The
continuations passed to `search', on the other hand, must speak the
CPS protocol, and thus almost certainly can't be previously-written
functions (unless you're a huge CPS fan).

Regards,

Wolf

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

"Simplicity does not precede complexity, but follows it."
--Alan J. Perlis