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)
|
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.