Le mar. 3 mars 2020 à 05:44, John Cowan <xxxxxx@ccil.org> a écrit :
>
> 0) I want to say that this is good work and that my criticisms are only an attempt to make it even better.  Thanks for doing this.

Thanks a lot for your feedback.

> 1) I don't understand what the point of exposing json-tokens is.  It seems to be useful only if you want to be able to read malformed JSON, which I can't see as a use case.

The point is to make it possible for some one that does want to rely
on the trampoline code and have fast parser without re-implementing
the tokenizer.

> 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).

I will make `(current-input-port)` the default value of `json-tokens`.

>
> 2) A generator implies reading, so json-generator-read might as well just be json-generator (and the same for json-accumulator-write).

I will do

>
> 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.

I will do.

>
> 4) Boolean is left off the list of things returned by json-generator[-read].
>

Done

> 5) If you don't do 3, just for readability change the examples of pairs into dotted-pair (datum) notation rather than Scheme expressions that evaluate to the pairs.
>

I will do.

> 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.
>

I will do.

> 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)

That is the case, it is implicit in the following sentence from specification:

> In cases where the JSON is invalid, the generator returned by json-generator-read should raise an object that satisfies the predicate json-error?.

> 8) The explanation of json-fold is not easy to understand.

I agree.

> Exactly how do values get added to the internal representation of an object or array?

Like the fold procedure, values get added to the internal
representation of an object or array in `proc`. The associated object
or array are finalized in resp. object-end or array-end.

> 9) There is no default for json-read.  The value of (current-input-port) would make sense, but see below.
>

I will do.

> 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.
>

json-read is straightforward to define in terms of json-generator
given json-fold. The current definition is given in the specification
of json-fold.