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 28 May 2020 07:05 UTC

Hello Alex,

Le lun. 25 mai 2020 à 02:47, Alex Shinn <xxxxxx@gmail.com> a écrit :
>
> json-tokens is a lexer, but many common parsing techniques
> do not make use of lexers at all, so this is exposing a specific
> implementation detail
>
> We can instead have json-fold take an input port and allow
> implementations to choose their own parsing strategy.

Ok, you are at least the second person to say that. I do not know
those techniques. Still I will replace json-tokens with a port or
generator.

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

> Also generators discourage fast FFI implementations for non-native-compiled
> Schemes.  Chibi-Scheme is slow but can beat the fastest
> compilers on simple I/O tasks, so it would be a shame to put it
> at a disadvantage here.
>
> 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.

Anyway, popularity should not prevent us from doing the good
thing. In this case, the point of the parameter is to fail fast in
web applications. _The default value is infinity._ But it is expected
to change the value to something reasonable depending on the
application when moving to production. The reason is that parsing
any broken deeply nested JSON can lead the implementation to
crash or fail in no obvious way which makes the JSON parsing
an ideal attack vector for a Denial of Service kind of attack.