Am Di., 23. Apr. 2019 um 17:02 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:
>
> I apologize for the very long delay.
>
> On Fri, Apr 5, 2019 at 10:00 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> (1) For the sake of applicability and coherence, SRFI 166 should be
>> compatible with SRFI 165. Problems that may be an obstacle to that
>> should (and can) be addressed in either SRFI 165 or SRFI 166 before
>> both are finalized.
>>
>> When a future SRFI standardizes the notion of monads, SRFI 165 should
>> and would become an implementation of that notion, so SRFI 166 would
>> automatically gain from it.
>
>
> I'm sorry but I still fail to see any practical example where an explicit dependence on SRFI 165 is an advantage.

The main reasons are simplicity, composability, and usability.

Consider lists. There is an abstract concept of a list, which is used
by many libraries of R7RS-large. Then there is a particular
implementation of lists, namely through linked pairs. Luckily, the
R7RS libraries making use of an abstract list type all use that
particular implementation. This makes the resulting standard more
simple, allows one to compose procedures provided by different
libraries, and makes the whole system more usable as (for example) I
can use SRFI 1 procedures wherever lists are involved.

It's analogous when SRFI 165 and SRFI 166 both become part of the same
standard. SRFI 166 uses the abstract concept of monadic values and
procedures and thus needs an implementation. SRFI 165 provides a
general implementation and basic combiners for monadic procedures.
There may be further SRFIs in the future that build upon an
environment monad as well. As in the list example, it is very
advantageous if they all build upon the same implementation.

As for another example, all container types build upon the same
comparator library.

The only reason for SRFI 166 to not depend on SRFI 165 would be if the
interface/the implementation of SRFI 165 fails to meet the needs of
SRFI 166. But that doesn't appear to be the case (indeed, SRFI 165's
implementation provides everything the original implementation in SRFI
159 provides and is as lightweight). If it were the case, SRFI 165
might have to be tweaked.

There are also a number of concrete advantages for SRFI 166 to depend
on SRFI 165:

(1) As I have already written on this list, SRFI 166's formatters do
not form a general monad. In general, monadic values can have general
values but the monadic values (the formatters) of SRFI 166 only have
the void type. For example, when writing an higher-order formatter,
with the interface of SRFI 166 I cannot pass values from one formatter
to the next in a sequence of formatters (in other words, SRFI 166
provides no "bind" (">>=") operation).

That, however, is needed when one wants to write efficient and pure
(in the functional programming sense) higher order formatters as I
would otherwise have to use mutable state to pass results between
subsequent formatters. The original implementation of SRFI 159 (for
example in the implementation of "written" and so on) makes a lot of
use of mutable variables. In my alternative implementation (not
published yet), I wanted to get rid of that (which has, in particular,
the advantage that it allows more non-local control flow between
formatters). But for that, I needed the full power of monads.

Now, SRFI 166 could be amended by describing a "bind" operation and so
on, but instead, it is much easier if SRFI 166 just referred to SRFI
165 where the monad is already fully described and specified.

(2) SRFI 165 is very precise about when which monadic values are
evaluated (computed) and will (before the final draft) include a
paragraph describing how the monadic procedures behave with respect to
tail calls and non-local control flow. Specifying these things are
standard for the standard procedures and the standard syntax of R7RS
and I see no reason why we should try to achieve the same standard
when it comes to the libraries of R7RS-large.

Again, it probably doesn't make sense to include all that in SRFI 166
as it distracts from the main purpose. However, when SRFI 166
explicitly refers to SRFI 165, everything is fine.

(3) SRFI 165 has a number of monadic procedures and helpers like
"make-computation", "bind/forked", etc. that SRFI 166 does not provide
(which, again, is fine because the focus of SRFI 166 is more about
providing formatters and less about providing the infrastructure to
write (higher order) formatters). In writing my alternative
implementation of SRFI 159/166, I have been making use of a lot of
these SRFI 165's procedures/syntax to write the formatters of, say
(srfi 166 columnar). And, indeed, by using these abstractions, my code
looks much more elegant and maintainable than without.

Think of SRFI 1. We do not necessarily need it to write code
processing lists, but with the provided abstractions of SRFI 1 like
"fold", "filter", etc., it becomes much productive and elegant. SRFI
165 can only provide the same for environment monads when other SRFIs
using the concept of environment monads have a SRFI 165
implementation.

[...]

-- Marc