From: Hakan Soderstrom
Subject: Re: Virtues of Lisp syntax
Date: 
Message-ID: <SODER.90Sep11141859@basm.nmpcad.se>
The syntax of Lisp is about the same as the syntax of
Assembler: it doesn't exactly stop you from doing what you
want, but it doesn't help either. Almost all kinds of errors
appear as run time errors.

Jeff Dalton writes,

>My view is just the opposite.  It's fortunate that a readable
>external syntax can correspond so closely to a flexible, easily
>manipulated data structure.

Yes, this is the crux of the matter. It also means that the
syntax is a compromise between machine readability and human
readability. Because it was designed in the 60's, there is a
bias towards machine readability. You help the compiler
build its data structure.

Goodness. I promised never to enter a syntax argument again
... it is one of those sure-to-flame topics. But it is fun!
And where would we be without Lisp?

	- Hakan

--
----------------------------------------------------
Hakan Soderstrom             Phone: +46 (8) 752 1138
NMP-CAD                      Fax:   +46 (8) 750 8056
P.O. Box 1193                E-mail: ·····@nmpcad.se
S-164 22 Kista, Sweden

From: Jeff Dalton
Subject: Re: Virtues of Lisp syntax
Date: 
Message-ID: <3407@skye.ed.ac.uk>
In article <···················@basm.nmpcad.se> ·····@nmpcad.se (Hakan Soderstrom) writes:
>The syntax of Lisp is about the same as the syntax of
>Assembler: it doesn't exactly stop you from doing what you
>want, but it doesn't help either.  Almost all kinds of errors
>appear as run time errors.

Actually, Lisp syntax does help many people to do what they want.
It's certainly much more helpful than assembler.  Maybe it doesn't
help *you* to do what you want, but so what?  No one ever claimed
Lisp was the answer to all problems.

Of course people who think run-time checking is the worst of all
possible sins won't like Lisp.  Those people would do well to use
another language instead.  ML is a good choice if they want most
of the type work done for them.

>Jeff Dalton writes,
>
>>My view is just the opposite.  It's fortunate that a readable
>>external syntax can correspond so closely to a flexible, easily
>>manipulated data structure.
>
>Yes, this is the crux of the matter. It also means that the
>syntax is a compromise between machine readability and human
>readability. 

That's exactly what it doesn't mean.  In order to be a compromise it
would have to be worse for humans (as compared to other programming
languages -- because every programming language makes such compromises
to some extent) in order to be better for machines.  

But, as I pointed out before, (many) Lisp programmers don't regard it
as worse for humans: they prefer it to the more Algol-like syntaxes.
Critics of Lisp's syntax consistently ignore this point and suppose
that the syntax must be a cost rather than a benefit.

Of course, some people who dislike Lisp syntax may also happen to
think the syntax is good for machines.  But it's only because they
prefer the syntax of other programming languages that they see Lisp as
making a greater compromise.  And different preferences are just what
we expect on questions of syntax.  Different people prefer different
things.  It might be nice if everyone preferred the same syntax, but
it isn't so.

In any case, the idea that Lisp is more of a compromise than other
languages seems rather bizarre.  It may seem plausible (to some) if
we restrict ourselves to syntax.  But Lisp is notorious for being
unsuited to "conventional" machines.  (Before anyone flames me,
let me point out that I think Lisp can be implemented effectively
on conventional machines.  Nonetheless, it has a reputation that
is not entirely unjustified.)

>Because it was designed in the 60's, there is a
>bias towards machine readability. You help the compiler
>build its data structure.

There might be something to this if it weren't the case that
other languages designed at about the same time, such as FORTRAN
and Algol 60, didn't show the same "bias".

In any case, you're confusing the origin of Lisp syntax with
the question of whether it really is readable.

-- Jeff
From: Jeffrey Jacobs
Subject: Re: Virtues of Lisp syntax
Date: 
Message-ID: <20301@well.sf.ca.us>
Having watched the LISP Syntax thread for a while, I thought a little
history might be in order...

Way back in the old days, development in LISP and the underlying
philosophy of the language were substantially different.

LISP was an interpreted language.  Debugging and development was done in
interpreted mode; compilation was considered the *last* step in the
development process.

LISP had two fundamental data types, CONS cells and ATOMs.  ATOMs were
"indivisible", and included "interned symbols", numbers and strings.
(Arrays were added, but were less important to the underlying
concept).

A key aspect of the language was the "equivalence of data and (source)code",
i.e. code consisted of LISP stuctures, which could be manipulated *exactly*
like any other LISP structure.  Note that this is substantially
different from the modern view, where "functions (*not* code) are a data
_type_" and not directly modifiable, e.g. even "interpreted" code in
most modern implementations
gets converted to something other than a CONS based structure.

This "equivalence" allowed some very interesting capabilities that are
no longer available in modern implementations.  Since the interpreter
operated on list structures, it was possible to dynamically modify code
while in the process of execution.  Now, most of us didn't write
self-modifying code (although we probably all tried it at least once).
But we were able to stop an execution, and make changes to code and
continue from the breakpoint without having to recompile or start over.
We could issue a break, put a trace point around an expression *within*
a defined function, and continue.  Or we could fix it, and continue;
the "fix" would be propagated even to pending calls.  E.g. if you
had
(DEFUN FOO (X Y)
  expr1
  expr2
  ...)

and expr1 invoked FOO recursively, you could break the execution,
change expr2 (or TRACE it,  or BREAK it or...), all of the pending
invocations on the stack were affected.  (You can't do this with
compiled code).

It allowed things like structure editors (where you didn't need to
worry about messing up parends), DWIM, and other features that have
been lost in the pursuit of performance.

With this view (and combined with the mathematical purity/simplicity
of McCarthy's original concept) LISP syntax not only makes sense,
it is virtually mandatory!

Of course, it also effectively mandated dynamic scoping.  "Local"/lexical
scoping really came about as the default for the compiler primarily because
most well written LISP code didn't use function arguments as free/special
variables, so it was an obvious optimization.  However, several years
ago, Daryle Lewis confided in me that he had intended that UCI LISP be
released with the compiler default set to everything being SPECIAL.
Given the historical problems in reconciling local and free variables,
and the fact that the vast majority of LISPers who learned the language
in the '70s and early '80 learned UCI LISP, I can't help but wonder
if what affect this might have had on Common LISP...

(FWIW, REDUCE was originally done in UCI LISP way back in the early '70s,
and BBN/INTERLISP supported MLISP, an Algol like syntax.  Seems to me that
RLISP must go back that far as well.  Given that structure editors are
incredibly ancient, I wonder why the people at Utah didn't use one of
those.  Oh, and almost nobody ever learned LISP using 1.5...

Personally, I think the whole reason LISP machines were created
was so that people could run EMACS :-)

However, if compilation is the primary development strategy (which it
is with CL), then the LISP syntax is not particularly useful.  Modern
block structured syntax is much easier to read and maintain; it also
allows constructs such as type declarations, etc. to be much
more readable.  Infix notation is indeed much more familiar to most
people.  Keyword syntax in most languages is much more obvious, readable
and certainly less prone to errors and abuse than CL.  The elimination
of direct interpretation of structures (as read) and the almost total use
of text editors does indeed leave LISP syntax a relic from the past.


Jeffrey M. Jacobs (co-developer of UCI LISP, 1973)
ConsArt Systems Inc, Technology & Management Consulting
P.O. Box 3016, Manhattan Beach, CA 90266
voice: (213)376-3802, E-Mail: ·········@COMPUSERVE.COM
From: Barry Margolin
Subject: Re: Virtues of Lisp syntax
Date: 
Message-ID: <1990Sep14.214946.8678@Think.COM>
In article <·····@well.sf.ca.us> ·······@well.sf.ca.us (Jeffrey Jacobs) writes:
>Way back in the old days, ...
>LISP had two fundamental data types, CONS cells and ATOMs.  ATOMs were
>"indivisible", and included "interned symbols", numbers and strings.
>(Arrays were added, but were less important to the underlying
>concept).

I don't know which "old days" you're referring to, but in the old days I
remember (I learned MacLisp in 1980) arrays predated strings.  PDP-10
MacLisp had just recently acquired a kludgey fake string mechanism, but
there was little support for anything but input and output of them.
Arrays, on the other hand, had existed since at least the early 70's.
--
Barry Margolin, Thinking Machines Corp.

······@think.com
{uunet,harvard}!think!barmar