TITLE: Two Views on Why Lisp's Syntax Matters
AUTHOR: Eugene Wallingford
DATE: March 12, 2013  4:30 PM
DESC: 
-----
BODY:
In year or so, I have seen a few people write to debunk the idea
that Lisp is special because its code is written in the primary
data structure of the language, list.  The one I remember best
is Dave Herman's
<A HREF="http://calculist.org/blog/2012/04/17/homoiconicity-isnt-the-point/">
   Homoiconicity isn't the point</A>,
which points out that the critical technical feature that makes
Lisp syntax powerful is that it can be <EM>read</EM> without
being <EM>parsed</EM>.

This morning I read
<A HREF="http://developers.slashdot.org/story/01/11/03/1726251/kent-m-pitman-answers-on-lisp-and-much-more">
   an old Slashdot post</A>
in which Lisp guru Kent Pitman gives a more philosophical answer
to the question about what makes Lisp's syntax so special:

<BLOCKQUOTE><EM>
I like Lisp's willingness to represent itself.  People often
explain this as its <B>ability</B> to represent itself, but
I think that's wrong.  Most languages are <B>capable</B> of
representing themselves, but they simply don't have the will
to.
</EM></BLOCKQUOTE>

That's a nice turn of phrase: &nbsp: Lisp is <B>willing</B> to
represent itself in data, whereas most languages don't have
"the will" to do so.  It's not about possibility, but facility.

It's easier to manipulate and generate programs from inside a
Lisp or Scheme program than any other language that most of us
might see on a daily basis.  Rubyists manipulate nested arrays
of symbols that encode abstract syntax trees, but this style
feels somewhat artificial, and besides Ruby's syntax is so
large that it's hard for a Ruby program to process other Ruby
programs in this way.

As Pitman says, the fact that Lisp programs are represented by
lists is almost besides the point.  It might well have been
arrays of some other data structure.  The key is that it is
the program's <EM>structure</EM> being represented, and not the
character-level syntax of the programs.  This is the same reason
that code can be read without being parsed, and that the macro
system can be so powerful.

It's also what makes it so easy to provide powerful support for
programmers in their text editors and other tools.  These tools
don't require a lot of machinery or runtime to navigate and
manipulate program code.  The structure of the code lies close
to its surface.

In the end, I like have two ways to think about Lisp's and Scheme's
syntactic advantages: the technical reasons that live in the
<TT>read</TT> procedure and the visceral reasons that embody
how programmers feel will they work with a syntax that is
willing to help the programmer.
-----