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.
Some of the bugs/fixes are really obvious. Some of my fixes I might not have implemented exactly how you might like. chibi is not my project, so I won't argue about changes to chibi. I tried my best to ensure at least one new test is added that demonstrates each fixed bug.
There are other issues pertaining to to the SRFI document or otherwise unresolved by my commits as follows:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Porting:
(srfi 130) dependency: the sample implementation relies on (chibi
string) which isn't quite (srfi 130):
(srfi 130) <--> (chibi string)
------------------------------------------
string-ref/cursor <--> string-cursor-ref
string-index <--> string-find
string-index-right <--> string-find-right
substring/cursors <--> substring-cursor
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.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
space-to
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")
...and the result should be "a b", not "a b" as shown in the document.
This interpretation is consistent with (tab-to ...) for the same argument
value.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
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.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
forked vs. fn-forked
Documentation says forked.
Code & tests say fn-forked.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
upcased, downcased and show-columns are not in the SRFI document (but definitely useful).
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
numeric/si
Documentation discrepancies:
1) The third test case (numeric/si 608 " ") is missing a base,
sticking 1000 or 1024 both work.
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.
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.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
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.
The logic to implement the documented conditional defaults is specific to
numeric, numeric/fitted, and numeric/comma.
No code change is suggested. But anyone writing a custom formatter should
know they cannot depend on a non-#f value in (fn (decimal-sep) ...)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
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"
;; 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"
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;