make json-stream-read a fold-like operation? Duy Nguyen (20 Jan 2020 09:47 UTC)
Re: make json-stream-read a fold-like operation? John Cowan (20 Jan 2020 14:18 UTC)
Re: make json-stream-read a fold-like operation? Amirouche Boubekki (21 Jan 2020 10:41 UTC)
Re: make json-stream-read a fold-like operation? Duy Nguyen (21 Jan 2020 12:52 UTC)
Re: make json-stream-read a fold-like operation? Amirouche Boubekki (21 Jan 2020 15:39 UTC)
Re: make json-stream-read a fold-like operation? Duy Nguyen (23 Jan 2020 09:08 UTC)
json-fold, json-slice and json-transformer (Re: make json-stream-read a fold-like operation?) Amirouche Boubekki (23 Jan 2020 10:05 UTC)

json-fold, json-slice and json-transformer (Re: make json-stream-read a fold-like operation?) Amirouche Boubekki 23 Jan 2020 10:05 UTC

Thanks Duy for requesting the fold-like procedure.

I read on the work of Oleg Kiselyov work on XML and SSAX. It is very
interesting [0][1]. The description of the foldts (extended tree fold)
is very inspiring. It seems to me it would be possible to make a
json-fold, the high level API of the JSON library layered on top
json-tokenize and json-stream-read. It should be possible to implement
json-read on top of it, and make it much more easy to create custom
json-read implementations (and avoid the continuation-passing-style
code in user case).

Maybe it will be possible to implement json-slice on top of it.

[0] https://github.com/arcfide/oleg/
[1] http://okmij.org/ftp/Scheme/xml.html

Le jeu. 23 janv. 2020 à 10:08, Duy Nguyen <xxxxxx@gmail.com> a écrit :
>
> On Tue, Jan 21, 2020 at 10:38 PM Amirouche Boubekki
> <xxxxxx@gmail.com> wrote:
> > Another thing we could poke at, is something like JSONSlicer [1]. It
> > looks like the following:
> >
> >   (json-read-slice selector port) -> generator
> >
> > Where SELECTOR is some kind of json selector (somewhat like CSS
> > selectors). The generator would contain full Scheme objects like
> > json-read does, but for the subset described by SELECTOR.  It will
> > help in the cases, where you want only some parts of a big JSON.

[...]

> >
> > What do you think about this slicer thing?
>
> Yeah it looks a lot like sxpath which should be in its own thing. And
> personally I'd rather have that separate from JSON. We have a JSON
> stream reader, we have a slicer that can handle any stream parser.
> Then we plug them together. People can replace the JSON stream reader
> with something else (even sxml) and it should still work.
>
> Actually maybe we just rip the sxpath out of sxml. The underlying
> engine (with sexp pattern, not xpath syntax) is really cool.

My thinking. I need to further investigate that, but maybe it can be
part of this SRFI.

> > [1] https://github.com/AMDmi3/jsonslicer

Looking up functional json parser, also yields https://github.com/chrisdone/jl

There is also http://objectpath.org/

--
Amirouche ~ https://hyper.dev