too low-level Alex Shinn (25 May 2020 00:47 UTC)
Re: too low-level Amirouche Boubekki (28 May 2020 07:05 UTC)
Re: too low-level Alex Shinn (28 May 2020 08:27 UTC)
Re: too low-level Alex Shinn (28 May 2020 09:10 UTC)
Re: too low-level Amirouche Boubekki (03 Jun 2020 06:01 UTC)
Re: too low-level Alex Shinn (04 Jun 2020 08:17 UTC)
Re: too low-level Marc Nieper-Wißkirchen (04 Jun 2020 08:53 UTC)
Re: too low-level Alex Shinn (04 Jun 2020 10:12 UTC)
Re: too low-level Marc Nieper-Wißkirchen (04 Jun 2020 10:28 UTC)
Re: too low-level John Cowan (04 Jun 2020 15:59 UTC)
Re: too low-level Marc Nieper-Wißkirchen (04 Jun 2020 16:29 UTC)
Re: too low-level John Cowan (04 Jun 2020 19:54 UTC)
Re: too low-level Marc Nieper-Wißkirchen (04 Jun 2020 20:55 UTC)
Re: too low-level Alex Shinn (04 Jun 2020 22:50 UTC)
Re: too low-level Arthur A. Gleckler (04 Jun 2020 23:32 UTC)
Re: too low-level John Cowan (05 Jun 2020 00:17 UTC)
Re: too low-level Alex Shinn (05 Jun 2020 04:07 UTC)
Re: too low-level John Cowan (05 Jun 2020 17:46 UTC)

Re: too low-level Amirouche Boubekki 03 Jun 2020 06:00 UTC

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.