Hacker News Reader

Why would code being a tree rather than a string necessarily differentiate it from other types of data? Surely, one could have non-code data that were also trees (think, just to pick a concrete example, of coded natural language data which are naturally represented as trees).

I thought the point in lisp was that the syntax for non-code data and code are the same so treating code as data (and thinking about code as data) is easier than in many other programming languages.

Please re-read the comment you are responding to. The answer is there.

The reason for this is that the tree organizes the program into pieces that are (mostly) semantically meaningful, whereas representing the program as a string doesn't. It's the exact same phenomenon that makes it easier to manipulate HTML correctly using a DOM rather than with regular expressions.

Mind. Blown. Your whole comment is incredible. I've never thought about it this way or realized what the value proposition was. Thanks!

Wow, thank you. Maybe I should write my own blog post. :-)

Check out: https://news.ycombinator.com/item?id=16395810

This is a very good comment and in my point much more valuable then the actual blog post.

I ask myself based on this world view if there are useful other representations beyond the popular choices of lists and strings. Apparently, lists (like in lisp) are already so universal that they can represent any kind of structural data.

Thanks for the kind words. Yes, lists are universal, but so are many other kinds of data structures (including strings, obviously, since there is a 1-to-1 mapping from lists to strings). So mere universality is not the killer feature.

In fact, there is no one "killer feature". It's a confluence of lots of little details. Two of the details that turn out to matter most is having symbols, and not having comas as separators in the surface syntax. Those two things are the difference between S-expressions:

(defun foo (x y) (baz (bar x) (bing y)))

and JSON, which can represent the exact same thing:

['defun', 'foo', ['x', 'y'], ['bar', 'x'], ['bing', 'y']]]

but obviously you wouldn't want to write your code like that.

You might be able to improve on linked lists as a code representation. You could, for example, use vectors instead of linked lists (i.e. cons cells) or maybe associative maps (i.e. dictionaries) as a core data structure. It's not hard to try out things like this in Lisp, so if you really want to know what happens, just grab yourself a Lisp interpreter (or even better, write one yourself) and try it.

Well said. And it got me thinking. -I wonder if this article is well known:

http://www.defmacro.org/ramblings/lisp.html

If not then people might enjoy a deeper dive into this kind of thing! For anybody who's not read it - since it's pretty long I'll try and sum it up with a quote from about 2/3 of the way down:

"Lisp is executable XML with a friendlier syntax"

This bit always comes to mind when I think of lisp and "code as data / data as code".

Code is ... nicely structured data that's easy to manipulate, general so that it represents anything and not just the idioms of that code, and with a straightforward text notation so we can conveniently work with any instance of that data, whether or not it's an existing idiom of the code.