Comments on: The parentheses of Lisp http://eli.thegreenplace.net/2006/11/10/the-parentheses-of-lisp/ Eli Bendersky's personal website Thu, 08 Jan 2009 00:30:42 +0000 http://wordpress.org/?v=2.7 hourly 1 By: Bill Birch http://eli.thegreenplace.net/2006/11/10/the-parentheses-of-lisp/comment-page-1/#comment-27084 Bill Birch Thu, 04 Jan 2007 03:09:08 +0000 http://eli.thegreenplace.net/2006/11/10/the-parentheses-of-lisp/#comment-27084 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. 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.

]]> By: Piggy Ziggy http://eli.thegreenplace.net/2006/11/10/the-parentheses-of-lisp/comment-page-1/#comment-7120 Piggy Ziggy Fri, 10 Nov 2006 20:01:58 +0000 http://eli.thegreenplace.net/2006/11/10/the-parentheses-of-lisp/#comment-7120 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 \ 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 \

]]> By: Jonathan Allen http://eli.thegreenplace.net/2006/11/10/the-parentheses-of-lisp/comment-page-1/#comment-7119 Jonathan Allen Fri, 10 Nov 2006 19:29:58 +0000 http://eli.thegreenplace.net/2006/11/10/the-parentheses-of-lisp/#comment-7119 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. 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.

]]> By: Pupeno http://eli.thegreenplace.net/2006/11/10/the-parentheses-of-lisp/comment-page-1/#comment-7115 Pupeno Fri, 10 Nov 2006 18:40:27 +0000 http://eli.thegreenplace.net/2006/11/10/the-parentheses-of-lisp/#comment-7115 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. 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.

]]> By: Phil Dawes http://eli.thegreenplace.net/2006/11/10/the-parentheses-of-lisp/comment-page-1/#comment-7091 Phil Dawes Fri, 10 Nov 2006 14:53:28 +0000 http://eli.thegreenplace.net/2006/11/10/the-parentheses-of-lisp/#comment-7091 Have you seen <a href="http://www.dwheeler.com/readable/readable-s-expressions.html" rel="nofollow">this?</a> Have you seen this?

]]> By: Cale Gibbard http://eli.thegreenplace.net/2006/11/10/the-parentheses-of-lisp/comment-page-1/#comment-7083 Cale Gibbard Fri, 10 Nov 2006 13:46:33 +0000 http://eli.thegreenplace.net/2006/11/10/the-parentheses-of-lisp/#comment-7083 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. 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.

]]> By: Johan Tibell http://eli.thegreenplace.net/2006/11/10/the-parentheses-of-lisp/comment-page-1/#comment-7082 Johan Tibell Fri, 10 Nov 2006 13:27:39 +0000 http://eli.thegreenplace.net/2006/11/10/the-parentheses-of-lisp/#comment-7082 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. 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.

]]>