4 ms·

The post [1] (though old) - hints at no good libs for json (mentions a workaround for one he picks) > For me, the most important quality I need in a JSON

by dhab 6y ago

The post [1] (though old) - hints at no good libs for json (mentions a workaround for one he picks) > For me, the most important quality I need in a JSON library is an unambiguous, one-to-one mapping of types. For example: some libraries will deserialize JSON arrays as Lisp lists, and JSON true/false as t/nil. But this means [] and false both deserialize to nil, so you can't reliably round trip anything! Although this post is from 2018, wondering if it has improved since then. [1] https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/#s48-st-json https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/#s4...

aerique 6y ago
I've been using `jsown` for all my Common Lisp JSON needs. There are more JSON libraries and I think JSON support for Common Lisp is good, not perfect, but no worse than most other popular languages. With regards to Steve's issues: ask yourself whether they apply to you.
junke 6y ago
This just works: USER> (yason:parse "{\"null\" : null, \"false\" : false, \"empty\": []}" :object-as :plist :json-arrays-as-vectors t :json-booleans-as-symbols t :json-nulls-as-keyword t) ("null" :NULL "false" YASON:FALSE "empty" #()) Null is mapped to the :null keyword, false to a symbol named false in the yason package, and the empty vector to an empty lisp vector (in Lisp #(1 2 3) denotes a vector, whereas (1 2 3) is a linked-list). All threes can be distguinshed from the others. All those options defaults to special (dynamically scoped) variables, so you don't have to pass them everytime. Encoding prints to the standard output (you can redirect it to an http stream, if you want), so you don't see double-quotes being escaped, but the string is equivalent (modulo spaces): USER> (yason:encode-plist *) {"null":null,"false":false,"empty":[]} The defaults in Yason just returns list for vectors, and map both null and false to nil, but this is not a problem: if you expect your field "items" to be a vector, then nil will denote the empty list, if you expect another field "enable-debug" to be a boolean, nil be good enough too. But in cases where you need to handle them differently, the library can help you distinguish among all kinds of value. See https://phmarek.github.io/yason/ https://phmarek.github.io/yason/
aidenn0 6y ago
That part of the post was wrong even in 2018. There were two libraries that had a one to one mapping out-of-the-box, and at least two others that could be configured to work that way.
flavio81 6y ago
>The post [1] (though old) - hints at no good libs for json That's his opinion. We have a lot of JSON libs, maybe too many. I use "jonathan" and i'm happy with it. EDIT: He wrote: "JSON support in Common Lisp is a god damn mess. There are an absurd number of JSON libraries and I don't really like any of them." He doesn't like any of them, but I do like more than one.

by dhab 6y ago

aerique 6y ago

I've been using `jsown` for all my Common Lisp JSON needs. There are more JSON libraries and I think JSON support for Common Lisp is good, not perfect, but no worse than most other popular languages. With regards to Steve's issues: ask yourself whether they apply to you.

junke 6y ago

This just works: USER> (yason:parse "{\"null\" : null, \"false\" : false, \"empty\": []}" :object-as :plist :json-arrays-as-vectors t :json-booleans-as-symbols t :json-nulls-as-keyword t) ("null" :NULL "false" YASON:FALSE "empty" #()) Null is mapped to the :null keyword, false to a symbol named false in the yason package, and the empty vector to an empty lisp vector (in Lisp #(1 2 3) denotes a vector, whereas (1 2 3) is a linked-list). All threes can be distguinshed from the others. All those options defaults to special (dynamically scoped) variables, so you don't have to pass them everytime. Encoding prints to the standard output (you can redirect it to an http stream, if you want), so you don't see double-quotes being escaped, but the string is equivalent (modulo spaces): USER> (yason:encode-plist *) {"null":null,"false":false,"empty":[]} The defaults in Yason just returns list for vectors, and map both null and false to nil, but this is not a problem: if you expect your field "items" to be a vector, then nil will denote the empty list, if you expect another field "enable-debug" to be a boolean, nil be good enough too. But in cases where you need to handle them differently, the library can help you distinguish among all kinds of value. See https://phmarek.github.io/yason/ https://phmarek.github.io/yason/

aidenn0 6y ago

That part of the post was wrong even in 2018. There were two libraries that had a one to one mapping out-of-the-box, and at least two others that could be configured to work that way.

flavio81 6y ago

>The post [1] (though old) - hints at no good libs for json That's his opinion. We have a lot of JSON libs, maybe too many. I use "jonathan" and i'm happy with it. EDIT: He wrote: "JSON support in Common Lisp is a god damn mess. There are an absurd number of JSON libraries and I don't really like any of them." He doesn't like any of them, but I do like more than one.