Le jeu. 28 mai 2020 à 10:27, Alex Shinn <xxxxxx@gmail.com> a écrit :
>
> On Thu, May 28, 2020 at 4:05 PM Amirouche Boubekki <xxxxxx@gmail.com> wrote:
>>
>> Hello Alex,
>>
>> Le lun. 25 mai 2020 à 02:47, Alex Shinn <xxxxxx@gmail.com> a écrit :
>> >
>> > I also don't see the practical use of generators here.  Perhaps
>> > an argument could be made for some core Scheme data type,
>> > but JSON is just a transmission format - we're unlikely to want
>> > to construct JSON dynamically for _reading_ purposes in Scheme
>> > (although we might want to dynamically generate on write to
>> > avoid the expensive in-memory representation).
>>
>> I am not sure which generators are not good. Can you point me to
>> a particular definition please?
>
>
> The port-or-generator argument to json-read.  I think it can just be a port.
>
>> > I'm not sure it's worth having the nesting depth limit parameter,
>> > as suitable values will be highly implementation dependent.
>>
>> That parameter does not seem very popular. In the JSON lib
>> coming in the standard library of Python there is no such limit,
>> there is only a global recursion limit which leads sometime the
>> CPython interpreter to crash. I think I saw some C library that has it.
>
>
> Yes, there will be implementation limits.  I suggest to mention in the
> SRFI that JSON parsing is subject to an implementation-defined
> depth limit, which should be no smaller than X (e.g. 100).

Done.

>
> Otherwise, the default value of infinity is of no use, and any other
> value will be difficult to determine and non-portable.

Like I tried to explain previously, the limit is applied to reading
and must be set on a per-application basis.