[erlang-questions] SAX-like JSON Parser for Erlang

[Bob Ippolito]

Sounds like I ought to fix up that documentation.

My primary goal was to just clone Apple's Key-Value Coding API (which I
should've stated more explicitly in the README). I never used this library
for anything but introspecting data structures interactively in the shell.
In that environment I find it to be friendlier if I can input the paths as
an atom or string. Efficiency wasn't much of a concern.

On Tue, Jan 22, 2013 at 9:29 PM, Richard O'Keefe <ok@REDACTED> wrote:

>
> On 23/01/2013, at 4:41 PM, Bob Ippolito wrote:
>
> > JSON pointers are much less powerful than XPath, it's not really a query
> language. No predicates, result must be a single node. It's just
> '/foo/bar/baz/0' instead of 'obj.foo.bar.baz[0]' (in JS).
> >
> > Something in-between (more powerful than JSON pointers, less powerful
> than XPath) would be something like https://github.com/etrepum/kvc -- It
> won't generate results from a stream, so you'd need to use it with a
> standard JSON parser.
>
> The examples in the README.md of https://github.com/etrepum/kvc
> do things like
>
> wibble =:= kvc:path(foo.bar.baz, [{foo, [{bar, [{baz, wibble}]}]}]).
>
> This feels wrong to me.  A path should be a _list_ of
> step descriptions, [foo,bar,bar].  Reasons:
> (1) You can have integer steps (this element of a tuple)
>     as well as atom steps (this entry in a dict &c).
>     And you can also have atom steps that _look_ like integers.
> (2) It is more efficient not to have to split a path into steps
>     at run time.
> (3) Perhaps the most painfully obvious:
>     a named step might need to include a dot (or any other fixed
>     character) in its name.
> (4) Given a recursive data structure with a small set of labels,
>     using dotted atoms you can quickly exhaust the size of
>     Erlang's atom table.
>
> In many ways, this is a perfect example of "strings are wrong".
> The abstract concept we need here is
>    "path"
> and
>    "path" = sequence of "step"
> and
>    "step" = receiver-specific position or label
>
> Packing a path up as a dotted atom or any other kind of
> string representation means having to recover at run time
> and unreliably information that has been _hidden_ inside
> the string, when it could have been made directly available
> as a simple data structure.
>
> I have a key-value component for my Smalltalk library, and
> in that (1,3,4) were not issues, but (2) had my programmer's
> instincts screaming 'this is a bad idea'.  In fact one of the
> things on my TODO list is to replace
>         aPath subStrings: ' .' asClass: Symbol trimmed: true
> by
>         aPath _steps
> in order to let aPath be returned if it's a sequence of steps
> already.
>
> Fortunately(?) the README.md is incomplete, and that KVC
> implementation _does_ accept a list of steps (which look as
> though they have to be binaries).  That module is better than
> it sounds.
>
> By the way, things like this remind me irresistibly of
> Nicklaus Wirth's "Professor Cleverbyte's Visit to Heaven"
> (Software Practice and Experience, Vol 7 pp155-158, 1977).
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130122/056f94d1/attachment.htm>