Here are my comments on SRFI 159 (Draft #1 published: 2017/8/21).

I wrote most of these a while back but held off on sending them because
they are mostly (but not all) related to the sample implementation and
the SRFI notes things may be out of sync.  I think I might as well send
them all at this point.

  - Caveat: My testing of the reference implementation is based on
    manually pulling files out of the Chibi Scheme repository by
    examining dependencies starting from show.sld, so I may have
    missed something. (Is there an easier way?)  Although I have
    Chibi installed, I wanted to test on a non-Chibi system to check
    portability.  I used Larceny with the -r7rs flag and then
    imported (chibi show) for my tests (in addition to (scheme base)
    and other standard things).

    - Here is the 'tree' of the files I pulled:

      .
      `-- chibi
          |-- monad
          |   |-- environment.scm
          |   `-- environment.sld
          |-- show
          |   |-- base.scm
          |   |-- base.sld
          |   |-- show.scm
          |   `-- write.scm
          |-- show.sld
          |-- string.scm
          `-- string.sld

  - Missing in implementation [I realize the SRFI document indicates
    things may be out of sync with the implementation, but thought it
    may be worthwhile to record]:
    - escaped maybe-escaped
    - numeric/comma numeric/si numeric/fitted
    - columnar
    - wrapped wrapped/list wrapped/char
    - justified

  - Implementation of 'numeric' seems to support only one argument.
    For example, (show #f (numeric 34.397 23)) gives an
    argument-count error.

  - In 'escaped': Do quote-ch and esc-ch default to #\" and
    #\\ resp.?  Also, would it be useful to permit the renamer
    procedure to map a character to more than one character?

  - In 'numeric/si', should there be a space between the numeric and
    suffix parts of the resulting string?  I think including a space
    is the SI recommendation (but I am not sure).  It may be useful
    to have an option for such a space, if it is not the default.

  - In space-to.: Perhaps obvious by Scheme conventions, but a brief
    note that columns are numbered starting at 0 may be worthwhile.
    Also, is it an error (or a no-op?) if the column argument is not
    a nonnegative integer?

  - Padding: In the implementation, padded and padded/right produce
    identical results, matching those shown for padded/right in the
    description.  I found that padded/left seems to do what the
    description says padded does.

  - A situation similar to the above seems to also exist for the
    'trimmed' and 'fitted' groups of formatters.

  - For trimmed/both and fitted/both, does 'width' have to be at
    least *twice* the width of 'ellipses'?  The current
    implementation raises an error if not.

  - In trimmed etc., is it true that the fmts are invoked in
    left-to-right order only as needed.  (The description seems to
    indicate so.)

  - Will the optional extensions in Columnar Formatting have a
    suggested library name or other easy way for detection?  Also,
    are these the only optional parts, or are there others (color,
    unicode, etc.)?

  - For columnar, is it true that in cases where 'width' (e.g., 78)
    is not divisible by the number of columns (e.g., 5), the extra
    space is allocated column-wise left to right (e.g., 16, 16, 16,
    15, 15)?

  - For wrapped, would it be useful to accept an optional
    splitting-predicate to use instead of the default
    char-whitespace?  We could use wrapped/list in such cases, but
    then we give up incremental output.

  - Minor

    - The implementation section has a link to code.google.com which
      forwards to github.  Given the status of code.google.com, perhaps
      another URL (via synthcode.com perhaps) is preferable.

    - The description of joined/range has a "\scheme{#f}" in the text.

Regards,

-chaw