Re: Reasons for preferring Lisp, and for what

• Previous message: Conrad Barski: "Re: LISP & "The Art of Unix Programming""
• In reply to: Tuang: "Reasons for preferring Lisp, and for what"
• Next in thread: Anton van Straaten: "Re: Reasons for preferring Lisp, and for what"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: 4 Nov 2003 18:31:45 -0800

There are so many reasons to prefer Lisp, you could fill a newsgroup
with them. But I'll choose just one item in your post...

tuanglen@hotmail.com (Tuang) wrote in message news:<df045d93.0311041316.288d8549@posting.google.com>...

> But it appears to me that the purpose is to enable the building of
> abstractions that, since they retain the same s-expr syntax as their
> components, can be built into yet higher-level abstractions, in a way
> that is somehow superior to the building up of abstractions by nested
> objects or just functions that call sub-functions in a procedural
> language.

The syntax *is* superior to nested function calls. The main thing to
note is that C/Algol-family function calls are the same form as
s-expressions, with the parethesis moved slightly, and extra commas
inserted instead of white space. They nest just fine, because the
syntax is uniform. But any other aspect of C/Algol family languages
breaks that syntactic unity. Loops, if/thens, blocks with declarations
all start to look different. In Lisp, all those things look very
similar.

One of the beauties of s-expressions as the complete expression of
program structure is that macros can always take an arbitrary chunk of
code and assume it is an s-expression or a sequence of s-expressions.
The advantage gained by this feature is that macros are free of the
"syntax protection" and limitations of other macro languages.

Consider a typical cpp macro that incorporates multiple C statements.
Where can it be used? Well, better make sure it has balanced braces so
that one can use it as a code block. If your macro needs to be an
expression (i.e., return a value), you need some exceedingly clumsy
use of the comma operator, and extra parentheses to make sure it
works. Not to mention all the backslashes you need to put it all in
one text line. And remember to protect against multiple evaluation by
making up some unique names for temporary variables. The syntax of a
chunk of C-code is always sticking out, and you need to cover it with
a bunch of layers of wrapping if you want to put it in a container.

The chunk of Lisp code has all these smooth, curvy ends ((like)
(these)) and always fits just where you want to put it.

This is all just one example of how Lisp is designed to smoothly allow
for abstraction. Integers that don't wrap around on overflow is
another. Abstraction is the most powerful tool around for managing
complexity, and Lisp does abstraction like no other language. I can
barely stand to program in anything else.

• Previous message: Conrad Barski: "Re: LISP & "The Art of Unix Programming""
• In reply to: Tuang: "Reasons for preferring Lisp, and for what"
• Next in thread: Anton van Straaten: "Re: Reasons for preferring Lisp, and for what"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]