> > I know Gauche supports json [1], and if this srfi was to be added to
> > Gauche, I would love to see Gauche's implementation reused with a thin
> > wrapper on top to provide the srfi api. Other schemes that already
> > support json might want to go the same route.
> >
>
> I will extend the early draft to make it possible to implement Gauche interface.

I made a mistake. Sorry, I will not make it *easier* to implement
Gauche JSON interface or other specific implementations, in this SRFI.
It is already possible to implement Gauche library with the current
code. I believe the purpose of a standard is to have some things that
are similar or prolly the same across implementations, in order to
make libraries and program portable across implementations.

And also, to make the life of the user *easier*.

There is already a copious number of JSON implementations, see
https://github.com/nst/JSONTestSuite/.

Quoting R7RS working group 1 charter:

>
> The purpose of this work is to facilitate sharing of Scheme code.
> One goal is to be able to reuse code written in one conforming
> implementation in another conforming implementation with as little
> change as possible.
>
> http://www.scheme-reports.org/2009/working-group-1-charter.html

One might say that is the RNRS charter, not the SRFI charter.

The srfi.schemers.org says:

> Since 1998, the Scheme Requests for Implementation (SRFI) process
> has been helping Scheme users write portable, useful Scheme code.
> We write concrete, detailed proposals and sample implementations for
> libraries and other additions to the Scheme language, and we encourage
> Scheme implementors to adopt them.

The purpose of the current SRFI is to have a common and shared library
that is portable for the time being relying on R7RS-large (because the
early draft rely on (scheme text)).

My goals with this JSON SRFI are to:

0) be interoperable with existing systems. That is json-read (new
name) must be able to read JSON produced by another system and
json-write (new name) must produce JSON that is readable by another
system.

1) be portable accross Scheme implementations

2) cover as much as possible use cases related to JSON parsing.
Compared to CPython's json module, the early draft support three other
use cases a) it is stream parser which can come handy in embedded
systems or when dealing with big files, b) given some efforts, it is
possible to adapt the output of the parser for faster downstream code
relying on records (instead of hashtable or alist) c) it can parse a
lot of nested array / objects, which is seemingly useless, except for
the fact that it allows to be robust (hopefully) to malicious JSON
text.

3) Performance comes last, it might not be the fastest JSON (even if I
avoid call/cc) but it opens the door to fine-tuned datastructures for
downstream code. It will avoid to approximatly double the memory
during full conversion (it helps the GC).

The SRFI will come in three parts:

0) The specification of the library

1) The sample implementation

2) The tests

Pick none, one, two or all of them!