[erlang-questions] Access JSON in Erlang like you do in JavaScript

[Ryan Zezeski]

I feel like a lot of people tend to feel pain when working with JSON in
Erlang. Especially when trying to access nested values. I wrote a blog
post about a way you can access JSON in Erlang using the same syntax you
would in JavaScript.

http://www.progski.net/blog/2010/destructuring_json_in_erlang_made_easy.html

-Ryan

[Jesper Louis Andersen]

On Tue, Oct 19, 2010 at 11:57 PM, Ryan Zezeski <rzez...@gmail.com> wrote:
> I feel like a lot of people tend to feel pain when working with JSON in
> Erlang.  Especially when trying to access nested values.  I wrote a blog
> post about a way you can access JSON in Erlang using the same syntax you
> would in JavaScript.

Have you considered wrapping the code into a parse transform so you
can "embed" the javascript notation into Erlang directly?

Another option is to write an xpath-like query tool, perhaps with a
Zipper construction on the parse tree so you have a neat continuation
for the next match, should you need it. This is probably my solution,
if I need to process JSON documents in the future. You already made
the first venture into this - think jQuery DOM selectors on steroids
for selection into JSON structures.

--
J.

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questio...@erlang.org

[Ryan Zezeski]

On Tue, Oct 19, 2010 at 8:24 PM, Jesper Louis Andersen <
jesper.lou...@gmail.com> wrote:

>
> Have you considered wrapping the code into a parse transform so you
> can "embed" the javascript notation into Erlang directly?
>
>

I have, and my first attempt was to use a parse transform. However, a parse
transform requires that it's valid Erlang syntax and I don't believe
something like "Obj.post.title" is considered valid Erlang syntax--correct?
You could do something like "Obj/post/title" but at that point it looks
more similar to XPath. Maybe I'll play around with this more.

Another option is to write an xpath-like query tool, perhaps with a
> Zipper construction on the parse tree so you have a neat continuation
> for the next match, should you need it. This is probably my solution,
> if I need to process JSON documents in the future. You already made
> the first venture into this - think jQuery DOM selectors on steroids
> for selection into JSON structures.
>

Huet's Zipper was definitely in my mind but I didn't do anything with it. I
think I like the sound of jQuery for JSON but I'm not sure what that would
look like. Has anyone done this in the JavaScript world?

Let's say I had an object like so:

var Obj = { posts: [{title: "Foo", body: "..."}, {title: "Bar", body:
"..."}, ...]};

Are you talking about having something like the following...

$(Obj, "title").each( function() { alert($(this).value); };

Pardon if my syntax is off, it's been a while since I've done
JavaScript/jQuery development.

[Robert Virding]

You could always write it in the form "{Obj,post,title}" which is valid syntax. Or do it without parse transforms and call functions with a syntax like:

fetch(Obj, {post,title})

This type of syntax, nesting using tuples, is used in OTP in places to access fields in nested property lists, and it is both legal erlang and not too ugly. Also much easier to implement function than parse transform.

Robert

________________________________________________________________

[Richard O'Keefe]

In Javascript you would access a single item using something like

thingy[i1][i2][i3]

where i1, i2, i3 are non-negative integer array indices or
string hash keys. Suppose you have an implementation of EEP 18
(http://www.erlang.org/eeps/eep-0018.html). Then

at(JSON = [H|_], Index) when is_tuple(H) ->
if is_atom(Index) ; is_binary(Index) ->
{value,{Index,Item}} = lists:keysearch(Index, 1, JSON),
Item
end;
at(JSON, Index) when is_list(JSON), is_integer(Index) ->
lists:nth(Index + 1, JSON).

at(JSON, I1, I2) -> at(at(JSON, I1), I2).
at(JSON, I1, I2, I3) -> at(at(JSON, I1), I2, I3).
at(JSON, I1, I2, I3, I4) -> at(at(JSON, I1), I2, I3, I4).

at_path(JSON, []) -> JSON;
at_path(JSON, [X|Xs]) -> at_path(at(JSON, X), Xs).

and now thingy[i1][i2][i3] becomes
at(Thingy, I1, I2, I3)
or at_path(Thingy, [I1,I2,I3]).

One example in the link would be

at(Obj, <<"post">>, <<"title">>)

Another would be just

at(Obj2, <<"person">>, <<"friends">>, 1)

Adjusting this to the data structure used by mochijson2 would be simple too.
It hardly seems worth adding special syntax and transformations to Erlang
for something this simple.

So what am I missing?

[Jesper Louis Andersen]

On Wed, Oct 20, 2010 at 4:12 AM, Ryan Zezeski <rzez...@gmail.com> wrote:

> Are you talking about having something like the following...
> $(Obj, "title").each( function() { alert($(this).value); };

Don't mind if the syntax is right or wrong. Yes, this is somewhat the
idea I had in mind. You want some kind of generic access on the
data-tree because otherwise you end up in a maze of small pattern
matches, all alike.

[Robert Virding]

A maze of twisty small pattern matches even.

Robert

[Ryan Zezeski]

On Wed, Oct 20, 2010 at 1:22 AM, Richard O'Keefe <o...@cs.otago.ac.nz> wrote:

>
> On 20/10/2010, at 10:57 AM, Ryan Zezeski wrote:
>
> One example in the link would be
>
> at(Obj, <<"post">>, <<"title">>)
>
> Another would be just
>
> at(Obj2, <<"person">>, <<"friends">>, 1)
>
> Adjusting this to the data structure used by mochijson2 would be simple
> too.
> It hardly seems worth adding special syntax and transformations to Erlang
> for something this simple.
>
> So what am I missing?
>

I don't think you're missing anything. I think you and Robert both make
great points. Although, there is a part of me that still likes the fact
that I can use JavaScript syntax with my solution.

I agree that using parse transformations for this is probably not the best
idea, but in the case of using Neotoma I'm only using parse transformations
during the parsing of the PEG. The output is just another Erlang module.
Of course, I'm assuming you already know this and you were referring to the
other ideas on the table. Just wanted to clarify for anyone else reading
this.

Maybe there is room for multiple solutions. You know...different strokes
for different folks. I wanted to share my finding as I hadn't seen anything
like it before.

Thanks for the input, everyone.