(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.

(2) Mathematically and in computer science, a monad can be modeled as
an endofunctor M: C->C, where C is the category of types. A monadic
value is a value whose type is of the form M(T). The monadic values
that appear in SRFI 166 are the formatters. However, SRFI 166 as
written only supports formatters of type M(void), not of a more
general type M(T). In the notation of Haskell, this means that only
the operation (>>) and not the operation (>>=, "bind") is meaningful.

In other words, SRFI 166 does not implement a monad in the general
sense, only a monoid (whose composition is given by the "each"
procedure). The title, "Monadic Formatting" is thus a bit misleading.

But I don't want to suggest to change the title, quite the contrary.
Instead, SRFI 166's formatter should be allowed to have arbitrary
monadic values. Only this allows a functional style when combining
formatters by using the "bind" primitive of monads.

When suggestion (1) is adopted, (2) will be automatically fulfilled.

(3) The sentence "A formatter essentially implement an environment
monad, although the underlying implementation is unspecified." does
not make much sense. A formatter is just a monoidal value. The
underlying implementation is independent of what the specification
models (which is, indeed, the environment monad modulo the points
raised in (2)).

(4) "unicode-terminal-width/jp": I am neither an expert on east Asian
fonts than on unicode" but I am wondering whether characters of
ambiguous width exist only in a Japanese context. Wouldn't
"unicode-terminal-width/cjk" be a better name?

(5) The current draft #2 of SRFI 165 adds an immutability flag to
state variables. I think it makes sense for SRFI 166 to adopt this
flag (it has to be added to "make-state-variable"). Currently, it says
under the description of "with!" that: "As the current formatting
state can be captured or reentered with continuations, with! should be
used with caution, and may produce unexpected output in cases."

This could and should be made a bit more precise by naming a number of
state variables that are immutable (like the "output" variable) and
forbidding changing them with "with!". All one may do is to re-bind
them with "with".

(6) The last sentence before the entry for "trimmed/lazy" is superfluous.

(7) How are the various "trimmed" procedures supposed to be
implemented in case ANSI escape sequences or Unicode combining
characters are present? (For example, when trimming happens to the
left, the suggested algorithm of taking the longest output does not
yield the correct result.)

(8) In trimmed/both, trimming has to be evenly distributed between the
left hand and the right hand side. Do we want to distribute by
character width or by character count?

(9) The description of "wrapped/char" says:

"As wrapped, but splits simply on individual characters exactly as the
current width is reached on each line. Thus there is nothing to
optimize and this formatter doesn't buffer output."

What is meant by "exactly" when the "string-width" of individual
characters can be larger than 1 so that the exact width cannot be
realized?

(10) SRFI 166 says that under the description of "columnar" that "... and
all but the last column are right-padded."

The reference implementation, however, also pads the right column, at
least according to the following test:
https://github.com/ashinn/chibi-scheme/blob/master/lib/chibi/show-test.sld#L701

In fact, the sample implementation makes a difference between a
char-whitespace? pad-char and a non-char-whitespace? one:
https://github.com/ashinn/chibi-scheme/blob/master/lib/chibi/show/column.scm#L201

What was the intention?

(11) The state variables "color", "bold", and "underline" should
either be documented so that they can be reasonably used by client
code or be made internal and not exported.

Thanks,

Marc