Hi Jim,

On Wed, Mar 28, 2018 at 6:59 AM, Jim Rees <xxxxxx@gmail.com> wrote:
I didn't have time to get into this SRFI back when it was being discussed.

I happened to have an application that could benefit from it, so I dug myself in for the past few weeks.   Overall, I'm quite happy with the concept, the compose-ability, & the laziness.

I found & fixed lots of bugs to make it work better on my own Scheme as well as chibi.

I forked chibi and added my commits to https://github.com/jimrees/chibi-scheme .   I have made no other commits to that fork unrelated to (srfi 159) / (chibi show).

Thanks very much!  I've merged these.  I'll also prepare a merge for the errata you found.

(srfi 130) dependency: the sample implementation relies on (chibi
string) which isn't quite (srfi 130):

Thanks, I'll change that.

The show sample implementation relies on:

(string-cursor-next str (string-cursor-end str)) ==> (string-cursor-end str)

...being able to call substring-cursor (substring/cursors) with only two arguments.
...being able to call substring (from (scheme base)) with only two arguments.
...being able to call string-cursor{<,<=,=,>=,>}? without the first string argument.

I was able to add a compatability layer to get around these dependencies for myself.   These have not been committed by my fork.

I'll check how many places I've done this and decide whether it's better to fix directly or use a compatibility layer.

The documented test case for space-to shows an incorrect number of spaces.

Given the rule that columns are zero-based, the length of the following
string should be 6.

(show #f "a" (space-to 5) "b")

Good catch, and the implementation agrees, I think this is safe to add as an errata.

padded vs padded/left vs padded/right code vs. document

There is still confusion here.

Document says padded means padded/left.
Code & tests say padded means padded/right.

The document is correct, I'll fix the code.


forked vs. fn-forked

Documentation says forked.

The document is correct.

Documentation discrepancies:

1) The third test case (numeric/si 608 " ") is missing a base,
sticking 1000 or 1024 both work.

Will add as an errata.

2) The code rounds to one extra decimal place.  One test example
depends on rounding to 1 place, while the last two depend on rounding
to two places.

It should round to one place.  The intent is to be consistent with Unix
tools which use --human-readable output, where the numeric value
should always take at most 3 characters including the decimal (but
not the suffix).

As this is not clearly stated I think it's safe to add as an errata.

3) The "micro" character in the SRFI document for the last two test
cases are actually U+03BC, Greek Letter Mu.  The sample implementation
uses "micro" U+00B5.

Good catch.  I think micro is more appropriate, and will add it as an errata.


state variable WRITER, defaults to WRITTEN per the documentation.

But this implies WRITTEN serves as a default implementation for
writing, but the exact opposite is true.  WRITTEN applies the value
of WRITER, which defaults to #f, or WRITTEN-DEFAULT.

It would be safer to say that WRITTEN applies the WRITER variable, whose
default is implementation-specific.



state variable DECIMAL-SEP, the doc says it defaults to "."

This is not quite accurate.  It defaults to #f.

I think it's better to change the implementation here.

numeric default behavior with unusual radix'es:

(numeric foo 10 #f) invokes (number->string foo 10) which for an
inexact real is required by R7RS to print a minimal number of decimal
place to unabiguously represent the value.

So, then it follows that (numeric foo radix) (with precision == #f) should 
generate distinct strings for distinct inexact values of foo for every radix.

;; 1) number->string fails to do this in chibi for radix 10
(import (srfi 144))

(number->string (fladjacent 1.0 0.0)) ==> "1.0"
(number->string (fladjacent 1.0 2.0)) ==> "1.0"

This is a bug in chibi, I'll take a look.

;; 2) numeric fails to do this for all the other radixes

(show #f (numeric (fladjacent 1.0 0.0) 9)) ==> "1.0"
(show #f (numeric (fladjacent 1.0 2.0) 9)) ==> "1.0"

This would definitely be desired if not expected, but is not made
clear by the SRFI and I think may go beyond an errata.  I think
we should consider this implementation-defined.