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

[Paul Davis]

And similar to kvc is the props library:

https://github.com/greyarea/props


On Wed, Jan 23, 2013 at 1:02 AM, Bob Ippolito <bob@REDACTED> wrote:

> 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).
>>
>>
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130123/d3f242f2/attachment.htm>