(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
