There are many ways of representing J's nouns in json, and many ways of representing json in J's nouns. But to convert between them in a consistent fashion, you have to live some simplifications.
For example, a J noun consists of type, shape and a list of values. So to fully represent a J noun in JSON all three of these should be emitted (and, for boxed arrays, this should be done recursively). But for most purposes this is an unnecessary complication. Similarly, if we went with this representation, we then have two different classes of json to be read back in. "Everything" and "the subset which could have been a representation of a J noun". Going the other direction, we can have a noun which is an exact representation of the value represented by arbitrary JSON (something other than a list of characters) and we have nouns in general. And the translation of a noun which is an exact representation of a JSON data structure would be translated to JSON using a different mechanism than the type/shape/list-of-values mechanism. Do you see how this pans out? Personally, I don't even parse the json which I'm currently working with. Instead, I treat it as a sequence of lines, where each line is a key/value pair. The key is between the first pair of double quotes on the line, the value is between the second pair of double quotes. If I was using JSON to transport arrays I would, of course, do this differently. So... getting back to your case: what is the problem you are trying to solve? If you start with the solution before you have identified your problem, you'll typically wind up solving the wrong problem. Thanks, -- Raul On Thu, May 15, 2014 at 3:30 PM, Marshall Lochbaum <[email protected]> wrote: > The addon convert/json ignores all but the first element of a > (non-boxed) array when using enc_json. > > enc_json 3 2 1 > 3 > enc_json 3 2 1;4 3 2 > [3,4] > enc_json <"_1 ]3 2 1 > [3,2,1] > enc_json <"_1 ]i.3 3 > [0,3,6] > > Is there a reason for this behavior? I realize that encoding 3 2 1 as > "[3,2,1]" is ambiguous (since (<"_1]3 2 1) has the same encoding), but > encoding as "3" seems even worse since it destroys data rather than > formatting. > > Is there a way around it without modifying the convert/json code? Of > course applying <"0 L:0 beforehand will suffice, but it is rather > inefficient and decodes to a boxed structure. The best possible solution > would be one that encodes any J noun unambiguously into reasonable JSON, > but either of the following would be useful: > - A method of conversion where dec_json is an exact inverse to end_json, > but the intermediate JSON may not make sense (e.g. it has extra > decorations for J arrays). > - A way of making any J noun a into another noun a1 such that > a -: dec_json enc_json a1 . > > Thanks, > Marshall > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
