Hacker News Reader

Comment by cwp | Hacker News Reader

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.

View on HN

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) do support these natively … and in a syntax that's better than JSON since you don't have to type all those annoying commas ;-)

You 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 ','.

Python 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.

I've never written any Ruby, but I refuse to believe that Ruby cares about which line has the comma. Am I misunderstanding something?

> 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....

> 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.)

Reply on news.ycombinator.com