9 ms·
Yeah, sure. S-expresssions are literals in Lisp, and can be "parsed" calling eval. But I think that misses the larger point made by the OP. JSON is really usefu
by cwp 17y ago
Yeah, sure. S-expresssions are literals in Lisp, and can be "parsed" calling eval. But I think that misses the larger point made by the OP. JSON is really useful even in languages other than Javascript. JSON wins over XML because XML is too complex and thus ambiguous. But JSON wins over s-expressions too, because s-expressions are too simple. How do you represent John Smith as an s-expression? Sure, it can be done. But as with XML, software that consumes s-expressions has to know how to interpret their structure, even if it doesn't have to parse the surface syntax.
- weichi 17y agoIt's true that s-expressions don't give you a literal syntax for hashmaps or arrays, but note that some lisps (e.g. Clojure) do support these natively … and in a syntax that's better than JSON since you don't have to type all those annoying commas ;-)
- sophacles 17y agoYou know I never quite got that comma thing. For instance in python, the only reason it is necessary is because {"foo": "bar" "baz", 'k2':'v2'} is the same as {'foo':'barbaz', 'k2':'v2'}. Getting rid of auto-concatination allows for {'foo':'barbaz' 'k2':'v2'} which is pretty easy to parse base on tokens and ':'. It also eliminates a pretty common bug, in which there is kv pair per line, and the line ends with ',', except for the last line which does not have the ','. (The following line has a '}'). The common bug being adding a new kv pair and missing the ','.
- blasdel 17y agoPython lets you put the commas before the items, like so: { 'foo':'barbaz' , 'k2':'v2' } Ruby doesn't like that though. Both Python and Ruby will ignore an extra trailing comma on the last item, which gives you another way of avoiding the common bug you describe.
- weichi 17y agoI've never written any Ruby, but I refuse to believe that Ruby cares about which line has the comma. Am I misunderstanding something?
- anamax 17y ago> It's true that s-expressions don't give you a literal syntax for hashmaps or arrays, but note that some lisps (e.g. Clojure CL's reader is especially rich, and it's programmable....
- anamax 17y ago> Yeah, sure. S-expresssions are literals in Lisp, and can be "parsed" calling eval. No on both counts. (1) S-expressions aren't literals. (2) s-expressions are not "parsed" by calling lisp eval. Lisp eval's argument is an s-expression - it doesn't parse anything. (It also doesn't read anything.) Lisp read turns character sequences into s-expressions. > But JSON wins over s-expressions too, because s-expressions are too simple. How do you represent John Smith as an s-expression? If you'd like, exactly the same way you'd represent it in JSON, because lisp's read handles a superset of the JSON datatypes. > software that consumes s-expressions has to know how to interpret their structure As does JSON. Take your example John Smith. What JSON datatype do you expect to get? (JSON just has numbers, strings, arrays, booleans, and hashes, where the keys have a restricted format.)