The parentheses of Lisp

November 10th, 2006 at 11:15 am

A couple of days ago a typical post appeared in the comp.lang.lisp newsgroup. In his post, titled “Lisp and Scheme with fewer parentheses”, the poster suggested “using a lisp/scheme with Python-style indentation for lists”. That is, indentation instead of the parentheses. Sample code:


   defun factorial (n)
     if (<= n 1)
       ^ 1
       * n
         factorial (- n 1) 

Expectedly for comp.lang.lisp, the post triggered a few acrid responses. But I've raved about this already. Now I want to discuss something else.

It eludes me why people want to take from Lisp the one feature that makes it superior to all the other programming languages - the list representation of code using those so-hated parentheses. In his wonderful book Paradigms of Artificial Intelligence programming, Peter Norvig lists seven features of Lisp that make it different from (and better than) other languages. Those features are:

  • Built in support for lists
  • Automatic storage management
  • Dynamic typing
  • First class functions
  • Uniform syntax
  • Interactive environment
  • Extensibility

Now, recall that the book was written in 1993, when there was yet no Java and the dynamic languages were in diapers. Compared with C++, Ada and Pascal, these features truly make Lisp stand out.

But this no longer is the case ! Perl shares six of these features with Lisp. So does Ruby, which also adds excellent object orientation on top. Guess which feature they don't share, though... Uniform syntax, of course. Uniform syntax - this wonderful feature of Lisp which makes code the same as data, allows the omnipotent macros that make the language so powerful. And this uniform syntax goodness is what those parentheses are for ! The Lisp concept of "form" - a list of symbols enclosed by opening and closing parentheses, which can either be data or code, is uniform syntax.

So, let me return to my original question. What on earth makes people want to take Lisp and remove the one feature that makes it so special ? If you have a problem with uniform syntax, just use Ruby or Perl.

Related posts:

  1. The sad state of the Lisp user community
  2. what’s up with the factorial ?
  3. newlisp – an intriguing dialect of Lisp
  4. Rant about Common Lisp and implementations
  5. rant about mailing lists

7 Responses to “The parentheses of Lisp”

  1. Johan TibellNo Gravatar Says:

    I guess one argument that could be made is that the syntax or lack of syntax is worth less than readability. Other languages might gain something by sacrificing the code-is-data property.

  2. Cale GibbardNo Gravatar Says:

    I don’t know if I feel the same way as you about this idea. The proposal you’re describing wouldn’t change the abstract syntax of lisp (which is what really matters for all the code-as-data stuff anyway), it’s basically just a change to the lexical syntax, giving the user another way to input what are essentially trees.

    One could even make this change at the editor level — designing an editor which hid parentheses according to some indentation rules even though it’s really saving them into the file.

    Really, we shouldn’t be so concerned if people want to display lisp code graphically as a tree display or in any number of other ways. It’s the uniformity of abstract syntax, not the concrete syntax which matters.

  3. Phil DawesNo Gravatar Says:

    Have you seen this?

  4. PupenoNo Gravatar Says:

    I think the matter is simple. Almost all the people that want to remove parenthesis from Lisp (like I wanted long ago) haven’t yet understood that source code is data, that it is a tree expressed by lists and that you can manipulate it.
    The moment I understood that I stopped wanting to get rid of parenthesis.
    I think it is inevitable that newcomers want to get rid of parenthesis, my advice would be to ignore that desire and continue learning. Experienced Lispers should repeat that over and over and over to them.

  5. Jonathan AllenNo Gravatar Says:

    Having the power to express code as data doesn’t mean you should always express code as data.

    There is no rule that says if you have syntax A, which is easy to write code against, you cannot also have syntax B, which is easy for humans to read.

  6. Piggy ZiggyNo Gravatar Says:

    Parentheses or whitespace, the uniform-representation power of lisp remains. Lisp “source” that the compiler operations on is defined in terms of lisp objects.

    It goes:
    external form (written lisp, usually sexps ) –lisp reader–> lisp object tree (source form, tree/lists made of conses and atoms) –macroexpander–> macroexpanded lisp object tree (like C post CPP application) –evaluator/compiler–>…

    The external format of lisp isn’t that relevant to the raw power of lisp. I don’t like whitespace because my brain doesn’t key off it. But if the parens were some other character pair, I’d be happy enough.

    Programmers learn that in C or Java, lots of parentheses means “big complicated expression where some, but not necessarily all, precedence rules are being overridden”.

    But parens are different in Lisp, they’re either just delimiters or all expressions are fully parenthesised, so there is no conflict with precedence to worry about resolving, either way, nor need to be scared.

    Changing the characters to something else might bypass that to help a non-lispers brain get over their false associations that () bring. Whitespace is just one such strategy for that.

    Consider:

    \defun fact \n/
    \if \

  7. Bill BirchNo Gravatar Says:

    Since this is probably about my post I feel I should reply. Just because Python has significant whitespace, does not mean we have to use all the rest of Python syntax. That would be madness IMHO.

    Actually the proposal does not change the best qualities of Lisp. The code-data duality is preserved. The only addition is that ‘significant whitespace’ can be used to lay out lists. And lists are how you write code. Read the intro here: http://www.lispin.org/wiki?page=default/IntroductionToLispin. This is not a big change really.