I added those procedures (even if they are very easy to implement and
might need to be re-implemented in user code because of the use of
custom scheme data types).

The parser will ignore RS character like whitespace and parse a
top-level value, which produces the expected behavior in
json-sequence-read.

See the pull-request at
https://github.com/scheme-requests-for-implementation/srfi-180/pull/5

Le sam. 20 juin 2020 à 09:30, Amirouche Boubekki
<xxxxxx@gmail.com> a écrit :
>
> Le jeu. 28 mai 2020 à 16:25, John Cowan <xxxxxx@ccil.org> a écrit :
> >
> > I contributed to that RFC and suggested the use of RS (record separator).  The idea of having such a thing is that if there is a syntax error in a particular JSON value, a stream processor can skip down to the next value reliably, which is not the case for whitespace..  I urge all authors of JSON parsers to check for and ignore an RS before a top-level JSON value is read (it may be preceded or followed by whitespace, of course).
> >
>
> If we make RS part of whitespace and allowed in JSON text unlike what
> the specification says, the implementation is similar to
> json-read-lines. Something along the line of:
>
> (call-with-input-string "[1]\n[2]\n[3]\n"
>   (lambda (port)
>     (let loop ((obj (json-read port))
>                    (out '()))
>       (if (eof-object? obj)
>         (reverse out)
>         (loop (json-read port) (cons obj out)))))
>
> The only difference would be to wrap json-read inside a guard and skip
> json-error?
>
> Mind the fact that json-read-lines is not part of the specification, so far.
>
> ref: https://datatracker.ietf.org/doc/rfc7464/
> ref: https://github.com/scheme-requests-for-implementation/srfi-180/blob/95e17fa77295f95a259215bf57e34f37d2fc08e9/srfi/180/checks.sld#L1427-L1455

--
Amirouche ~ https://hyper.dev