Xref: utzoo comp.lang.lisp:3672 comp.lang.scheme:1678
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!well!jjacobs
From: jjacobs@well.sf.ca.us (Jeffrey Jacobs)
Newsgroups: comp.lang.lisp,comp.lang.scheme
Subject: Re: Virtues of Lisp syntax
Message-ID: <20501@well.sf.ca.us>
Date: 18 Sep 90 21:36:03 GMT
References: <10466@life.ai.mit.edu> <6217@castle.ed.ac.uk> <10722@life.ai.mit.edu>
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 162


Larry Masinter writes:

> *Way* back in the old days, Lisp was batch. Punch cards & JCL.
> Although the first generation (Lisp 1.5 on 7040 and its ilk) may have
> been primarily interpreted, mmost of the second generation Lisps were
> compiled (I think I remember that in Stanford's Lisp/360 the DEFINE
> function invoked the compiler.)

I'm not sure which "second generation LISPs" Larry refers to.  Having
fortunately been spared any "batch LISPs" other than briefly and
mercifully SDC's, I can't comment.  Certainly, Maclisp, BBN/Inter-, UCI,
Stanford 1.6 meet my definition of being primarily interpreted during
the development process.  (I can't imagine anything more horrible than
programming LISP in a batch environment ;-)

>BBN Lisp had strings and arrays hash tables and a few other data types
>in the early 70's, and I don't think it was unique. Lisp 1.5 only had
>a few datatypes, though.

UCI and 1.6 also had similar data types.  What I meant to point out was
that the conceptual focus was on CONS cells and ATOMS as the *primary*
data types of interest.  As opposed to modern Common LISPs, where the
term "atom" had disappeared,
people are deathly afraid of using CONS cells, and the focus
seems to be primarily on sequences, hash-tables, vectors, etc.  (This
reached its peak in the SPICE litrature where users were warned to
'avoid the use of CONS whenever possible').

>if you deleted, added, or renamed an argument, you might start
>executing code where the variable bindings of the old stack frame
>didn't match what the new code expeced.

True, but protecting the programmer from dumb mistakes is not something
for which LISP is famous.  Even in a compiled environment, changing
argument lists still causes problems.  And in the interpreted mode,
you could often fix the roblem and continue, as opposed to starting over.


>[As a side note, many learning LISP programmers frequently do
> encounter self-modifying code and are mystified by it, e.g.,
>   (let ((var '(a b c)))
>       ...
>       (nconc var value))
> ]

This isn't self modifying code, it's destructive modification of a data
structure (and let's avoid a circular argument about "var" being "code";
the learning programmer encounters this as a data example, not an
example of code).

As an aside, destructive modification of structures, or even
the building of any structure that is not a fairly simple list,
seems to be something that either programmers don't learn or fear
greatly.  I know one former member of the committee that confessed
to never having used RPLACA or its equivalent.  See also the
recent thread on building lists and TCONC...

>As for dynamic error correction, insertion of breakpoints and trace
>points, however, the major impediment is not that Lisp is compiled:
>the major problem is the presence of *MACROS* in the language.

Sorry, this on doesn't fly.  The information needed for dynamic correction,
tracing, etc.  is simply gone.  You can't issue a break, followed
by a "TRACE FOO IN FUN" where "UN" is a compiled function, continue,
ad have pending call to FOO in previous invocation of FUN trace.
(The Medly example simply demonstrates this).

Nor can I buy the "MACROS" argument.  Most applications programmers(as
opposed to "language implementors"), make very little use of macros.  Nor
do they have much reason to do source level debugging of macros supplied
with their particular implementation.  IOW, *most* of their debugging is
done on functions, not macros.  And if they do use macros, they are usually
fairly simple and straightforward.

>I don't really know the demographics, but my impression was that the
>popular Lisp implementations of the '70s were MacLisp, Lisp 1.6, Franz
>Lisp, Interlisp, and that UCI Lisp wasn't so widely used. Maybe the
>distinction is between the research vs. the student community.

The distinction is indeed the "student community".  UCI LISP was,
according to my records and correspondence, the most widely used system
for *teaching* LISP.  In fact, it was used for classes at Stanford around '75
or '76, and was used at CMU into the '80s (CMU rewrote it).  I don't think
it ever was adopted by SAIL, although I'm sure they incorporated many of the
enhancements.  Certainly BBN/Interlisp and MacLisp were the premier
versions used in the research community, followed by Franz later in the
decade.  (I'm not real clear on what happend with 1.6; UCI was a
melding of Stanford 1.6 and BBN).

>I'm not sure about the REDUCE bit, although it doesn't ring true (my
>'standard lisp' history is a bit rusty)

Trust me; I was providing support to Utah while I was at ISI in 1974!

> but you certainly shouldn't
>confuse MLISP (which is the meta-lisp used in McCarthy's books) with
>CLISP (which is the DWIM-based support for infix notation that was
>added to Interlisp in the mid-70s.)

Mea culpa, it was indeed CLISP!  This was available at least as early
as '74.  My earlier BBN/Inter manuals are in storage, but I think it
might even go back a little earlier.

>I'm not sure what editor Griss
>and Hearn used for REDUCE, but I'd guess it was some variant of TECO.
>Remember that in the early 70's, people still actually used teletype
>machines and paper-based terminals to talk to computers; neither text
>or structure based editors actually let you *see* anything unless you
>asked it to print it out for you.

I remember, literally.  I used to have a TI Silentwriter next to two terminals
in my office...

>The ability to write programs that create or analyze other programs
>without resorting to extensive string manipulation or pattern matching
>has always been a strength of Lisp, whether or not you can do so on
>the fly with programs that are running on the stack.

Quite true!  And, I might add, the simple syntax of LISP makes it much
easier to write code that generates LISP code than is the case with other
languages.

>I guess C doesn't have a 'Modern block structured syntax' (I certainly
>get cross-eyed looking at some of the constructs that cross my
>screen); perhaps it is a relic from the past, too.

Heck, I get *serious* eye strain trying to read most C code.  Nobody
on this planet will ever accuse me of being a C-booster.  (And it
certainly qualifies as a "relic"; the biggest influence in C was
probably the difficulty in pushing the keys on the old ASR teletypes!)

>> Personally, I think the whole reason LISP machines were created
>> was so that people could run EMACS :-)
>I believe EMACS predated LISP machines by some margin

Hey, my point exactly.  More (?) than one EMACS user on a PDP-10 brought
it to its knees, so the LISP machine had to be invented :-)

>I think a lot of people find Lisp hard to
>read and maintain, and that the difficulty is intrinsic, but I don't
>think there is as strong a correlation with editor technology as you
>imply.

I didn't mean to imply any such correlation; in fact, I'm quite happy to
use ?MACS.  But I'd also like to have a structure editor, and DWIM, and
a lot of other things that are no longer available.  More importantly,
I'd like to have seen more of the underlying concepts and philosophy
maintained!

>(This may sound a little like a flame, but I don't mean it to be. Just
>comparing my recollection of History to Mr. Jacobs.)

No flame taken...

Jeffrey M. Jacobs
ConsArt Systems Inc, Technology & Management Consulting
P.O. Box 3016, Manhattan Beach, CA 90266
voice: (213)376-3802, E-Mail: 76702.456@COMPUSERVE.COM

"I hope that when I get old I won't jes sit around talking about glory days,
but I probably will" - Bruce Springsteen