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.
On Tue, Oct 19, 2010 at 11:57 PM, Ryan Zezeski <rzeze...@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-questions-unsubscr...@erlang.org
> 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?
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.
> On Tue, Oct 19, 2010 at 8:24 PM, Jesper Louis Andersen < > jesper.louis.ander...@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?
> 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.
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).
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?
________________________________________________________________ erlang-questions (at) erlang.org mailing list. See http://www.erlang.org/faq.html To unsubscribe; mailto:erlang-questions-unsubscr...@erlang.org
On Wed, Oct 20, 2010 at 4:12 AM, Ryan Zezeski <rzeze...@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.
-- J.
________________________________________________________________ erlang-questions (at) erlang.org mailing list. See http://www.erlang.org/faq.html To unsubscribe; mailto:erlang-questions-unsubscr...@erlang.org
> On Wed, Oct 20, 2010 at 4:12 AM, Ryan Zezeski <rzeze...@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.
> -- > J.
> ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscr...@erlang.org
________________________________________________________________ erlang-questions (at) erlang.org mailing list. See http://www.erlang.org/faq.html To unsubscribe; mailto:erlang-questions-unsubscr...@erlang.org
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.
