I think it makes more sense to pass a port-or-generator directly to json-generator-read and keeping json-tokens behind the scenes. Also, what is the default value of the argument? If it's a port-or-generator as I suggest, it should be the value of (current-input-port).
2) A generator implies reading, so json-generator-read might as well just be json-generator (and the same for json-accumulator-write).
3) Why not have json-generator[-read] return single datums instead of pairs? Just return one of the symbols start-array, end-array, start-object, end-object or null, or else a number, string, or boolean. That eliminates garbage collection pressure.
4) Boolean is left off the list of things returned by json-generator[-read].
5) If you don't do 4, just for readability change the examples of pairs into dotted-pair (datum) notation rather than Scheme expressions that evaluate to the pairs.
6) The point should be made somewhere that leading whitespace is deleted, and that a #\x1e; before top-level value is also ignored to support RFC 7464.
7) An EOF object while a JSON object is being built should explicitly raise a json-error, whereas one between objects (possibly after some whitespace is read)
8) The explanation of json-fold is not easy to understand. Exactly how do values get added to the internal representation of an object or array?
9) There is no default for json-read. The value of (current-input-port) would make sense, but see below.
10) It would be good if json-read could accept a json-generator, but unfortunately there is no way to discriminate between a json-generator and a string-or-char generator. Given string ports as standard, maybe string-or-char generators aren't so important.
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgA few times, I did some exuberant stomping about, like a hippo auditioning
for Riverdance, though I stopped when I thought I heard something at
the far side of the room falling over in rhythm with my feet. --Joseph Zitt