Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucbvax!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!odi!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.lang.lisp
Subject: Re: Unix Lisp Environments (why the slow evolution)
Message-ID: <370@odi.ODI.COM>
Date: 29 May 89 05:12:04 GMT
References: <31670@sri-unix.SRI.COM> <469@skye.ed.ac.uk> <1028@syma.sussex.ac.uk>
Reply-To: dlw@odi.com
Organization: Object Design Inc., Burlington, MA
Lines: 107
In-reply-to: aarons@syma.sussex.ac.uk's message of 27 May 89 07:40:06 GMT

It's true that programmers familiar with C or Fortran are sometimes
scared off by Lisp's syntax, because it's so different.  But I dispute
your claims that Lisp's syntax is *actually* inferior.

Lisp programs with nested loops and complicated nested conditionals
are quite easy to read, because all serious Lisp programmers indent
their code properly and uniformly (because their editors make it easy
to do so).  Indentation is how people really understand the groupings
involved in these loops and conditionals.  Try taking your Pop-11
example, and intentionally making *one* indentation error; for example,
take the "if S(item)" line, the fourth line in the body, and indent
it right under the third.  Nobody will understand the code any more.

I agree that the Pop-11 indentation syntax you show is better than
what's currently in Common Lisp.  This situation is due to an
unfortunately holy war in the Lisp community, whose members cannot
agree on an iteration construct.  In the Symbolics superset of
Common Lisp, here's what your example would look like:

  (loop for x in l1
        for y in l2 do
    (f x y))

It has this advantage over the Pop-11 syntax you showed: each variable
is grouped together with the expression that produces the list, so
it's clearly who goes with whom.  The above example is too trivial to
demonstrate the point; it's clearer when the expressions are larger
than "l1".  (By the way, the keyword "do" will probably be removed or
made optional in the version of "loop" proposed for Common Lisp; years
of experience show that it would work better that way.)

You talk about "a program that compiles and then behaves oddly"
because of mismatches of opening and closing syntax.  This never
happens in Lisp, when used with serious editors.  It may not be
apparent to you that editors would solve this issue so well, and I
don't know how to demonstrate it; I have spent over ten years doing
this kind of programming, and I'll have to ask you to take my word for
it.  Or ask some other experienced Lisp programmers who use equivalent
editors.


      ((.....) (.....))

  could mean almost anything, depending on the context: to work out that
  it is part of a conditional one has to look back to the beginning of the

In a very long "cond" on a very small screen or window, yes, this
is true.  On the other hand, if you are looking at a big procedure
through a tiny window, it's hard to understand what's going on even
if you do know which kind of statement is which.  I agree that this
can be a problem, but in practice, "cond"s usually don't get that
big, and modern serious Lisp programmers tend to have large screens,
so it's not much of a problem.  Comments in the code also work wonders
for readability, not only making it clear that you're looking at a "cond",
but (far more important) explaining what the code really means.

    More generally "(x y z)" in LISP could, depending on context, be a
    procedure call, a set of formal parameters, a set of local
    variables, a list of three atoms, a condition in a conditional, the
    consequent of a conditional, and so on.

    By contrast, POP-11 uses a large variety of keywords to distinguish
    syntactic contexts, instead of relying so much on POSITION to

I could equally well say that "xxx yyy zzz" could mean any number of
things in Fortran or C.  In all of the languages under discussion, you
tell what's going on via keywords.  In Lisp, you know that "(cond
...)" means one thing and "(defun ...)" means another.  It's perfectly
clear, without all those different punctuation marks.

    determine significance. Parentheses are used for procedure calls in
    the normal way, but distinct brackets are used for list expressions
    "[...]" and vectors "{...}" and this also helps to reduce cognitive
    load during reading. (This sort of thing is particularly important
    when large programs have to be maintained by programmers who were
    not the original authors.)

Ah, now you're talking about distinguishing between expressions and
textual constants.  One of the few punctuation marks that Lisp *does*
use is the single-quote, which makes it clear whether something is
a constant or not.  Even in a very big constant, where the single-quote
is far away, it is *immediately* apparent whether you are looking
at code or not, since code can easily be recognized by the keywords
and indentation.  The only exception, of course, is when the
constant *really is* a piece of list structure that works as Lisp
code, but of course such constants look like code.  Again, I have
to ask you to believe me that in years of maintaining other people's
programs, I hardly ever had any trouble distinguishing constants from code.

I don't know enough about Pop-11 to comment on its syntax, but a good
way to see the problems with one kind of conventional syntax is to
look at C.  (Yes, I saw that you don't think highly of C's syntax
either.)  There's a great book called "C Traps and Pitfalls" (or
something very close to that) that explains a lot of ways that you can
get fouled up by C's syntax.  My favorite: how do you write a C macro
that expands into a statement?  It's very hard to get this right.  The
tricky issue is whether the macro should include the semicolon or not,
and how this interacts with the "if" and compound statement syntax in C.
The book shows a way that works, but it's really an obscure kludge.
This is the kind of problem Lisp would never have, because its lexical
syntax is so simple and uniform.

It's true that many people who are familiar with other languages
are scared off by Lisp syntax, but it's too bad, because their
fears are not justified by the facts.

Daniel Weinreb     Object Design, Inc.     dlw@odi.com