Am Do., 2. Apr. 2020 um 22:56 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

On Thu, Apr 2, 2020 at 10:35 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

I am with Hume (and against Leibniz, as will appear below); I discredit metaphysical necessity.

If we call something a monad (and I guess people will talk about the Maybe monad), it should be a monad (on the relevant category).

When I said that, I actually had forgotten for the moment the connection between Leibniz and monads of another kind!

But what I am challenging is not the definition of monads or whether Maybe should be a monad (it should), but what the relevant category is. I believe that it does not need to comprehend all Scheme procedures, but only a subset of them.

We want to talk about "a monad in Scheme" as much as we can talk about "a monad in Haskell" without further qualifications. Not only will specifications be more wordy ("a monad on the category of single-valued procedures taking only a single-value"), it will also complicate things when we have different notions of monads in Scheme. Moreover, a uniform interface will be more complicated.

Thus, if we say the relevant category for the Maybe monad is the category of single-valued procedures taking only single-values it will lead to the fewest surprises if the same category underlies any other notion we officially dub "monad" in Scheme.

But this would also exclude too much from other interesting monads, like the Reader monod I described in SRFI 165 (a computation should really be able to take more than one value and yield more than one value).

Further, a monad T is first and foremost a functor that takes a procedure a -> b to a procedure T a -> T b.  If we sticked to single-valued functions taking only single values, we would have to explain to the user that they cannot uniformly lift any procedure. This is one instance why I claim that generalization is to simplify things by removing unnecessary restrictions.

In the case of the Maybe monad, the lifting would be:

(define (maybe-lift f)

  (lambda (maybe)

    (if (nothing? maybe) nothing

        (call-with-values 

            (lambda ()

              (call-with-values (lambda () (maybe-ref maybe)) f))

          just))))

With the current Maybe proposal, `maybe-lift' will only work for single-valued functions taking a single-value.

Even if we are not interested in multiple values, we are interested in procedures taking more than one value, but we would have to through them out.

"Calculemus". But everything we know about programming shows that it is not simply mathematics, though there are mathematical topics like incompleteness and complexity that are close.

I don't understand your point here.

Leibniz: "Quando orientur controversiae, non magis disputatione opus erit inter duos philosophos, quam inter duos computistas [people who do computations]. Sufficiet enim calamos in manus sumere sedereque ad abacos, et sibi mutuo (accito [future imperative: fetch!} si placet amico) dicere: calculemus."

This adds some list processing that is not part of the original problem.

But in fact we cannot program without adding material extraneous to the merely mathematical perspective: in this case, a list. (We also have the List monad, a very closely related idea.)

If you can make sure that such an upward compatible extension is possible, I would be most grateful (and may write such an optional extension). Please make sure that the procedures in SRFI 189, if possible, are stated in a way that actually makes it possible. (For example, "maybe-sequence" would have to be able to accept an optional argument that aggregates multiple values in a single value in an optional extension.)

Additional optional arguments are always in scope for Scheme (except R6RS), as are extensions to the acceptable type(s) of an argument.

Procedures that already take a rest argument are much harder to generalize by adding optional arguments.

So in my role as BDFL for SRFI 189, I rule multiple arguments and values out of scope.

That's a pity that the discussion has to end here par ordre du mufti, but I respect your decision.

Please note that I am *not* ending discussion, only ruling out certain actions on my own part (see the signature below). If there is a compatible or even competing SRFI, it will get an equal place on the eventual ballot.

It seemed to me that you wanted to say further discussion about whether to add Maybes taking multiple values to *this* SRFI is fruitless.  I said that this were a pity because I haven't seen a convincing argument not to implement a full monad (on all Scheme procedures) in *this* SRFI and no convincing argument why a full monad is useless here.

By the way, I didn't mean to take this discussion private, so feel free to send any part of it to the list.

I did so; mainly to publish the `maybe-lift' example.

-- Marc

John Cowan http://vrici.lojban.org/~cowan xxxxxx@ccil.org
The internet is a web of tiny tyrannies giving an illusion of anarchy.
--David Rush