Xref: utzoo comp.lang.lisp:3678 comp.lang.scheme:1682
Path: utzoo!attcan!uunet!cs.utexas.edu!hellgate.utah.edu!cdr.utah.edu!moore
From: moore%cdr.utah.edu@cs.utah.edu (Tim Moore)
Newsgroups: comp.lang.lisp,comp.lang.scheme
Subject: Re: Virtues of Lisp syntax
Message-ID: <1990Sep18.180829.8801@hellgate.utah.edu>
Date: 19 Sep 90 00:08:29 GMT
References: <10466@life.ai.mit.edu> <6217@castle.ed.ac.uk> <10722@life.ai.mit.edu> <20501@well.sf.ca.us>
Organization: University of Utah CS Dept
Lines: 115

In article <20501@well.sf.ca.us> jjacobs@well.sf.ca.us (Jeffrey Jacobs) writes:
>Larry Masinter writes:
>>...
>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.
>

I'd say that Lisp, with its copious runtime typechecking, does a
pretty good job of protecting the user from dumb mistakes, compared
with other languages like C.

>
>>[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).
>

It is self-modifying code in the sense that it changes the behavior of
the form from one evaluation to the next by tweaking a structure that
is not obviously part of the global state of the program. It's clearly
a hack that has been made obsolete by closures. It's not legal Common
Lisp code, because the constant may be in read-only memory.

>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...
>

A reason for this may be that one of the most influential Lisp books
of the 80's (IMHO), Abelson and Sussman's "Structure and
Interpretation of Computer Programs", does a pretty good job of
discouraging the pitfalls of destructive modification. Also, avoiding
destructive modification is sound engineering practice. Far too often
have I stumbled over someone's clever destructive hack when trying to
modify code.

I think many Lisp programmers go through a phase where they discover
the forbidden pleasures of destructive modification and go overboard
using it. I myself am starting to grow out of it. It causes too much
grief in the long run.

Also, in modern Lisps that use a generational garbage collector,
destructive modification of a structure can be as expensive if not
more than allocating a fresh structure.

>>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.
>...

>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.
>

It's not the macros that the application programmers write themselves
that cause problems; at least the programmer knows what the expansions
of those macros look like. Rather, it's the macros that are a part of
the language that cause trouble. Consider how often Common Lisp
programmers use cond, setf, dotimes, dolist, do, and do*. The
expansions of these macros can be pretty hairy. Maintaining the
correspondence between the internal representation of a function and
the form that produced it is not trivial.

>>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!

So that explains the old copy of the UCI Lisp manual in the PASS group
library... 

>>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 third this point. Many problems can be solved cleverly and
efficiently by generating code for the solution instead of solving the
problem directly. Pattern matchers come to mind. To return briefly to
the original subject of this thread, I don't think that the trend
towards an opaque function representation has effected this capability
at all.

>
>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
Tim Moore                    moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Ah, youth. Ah, statute of limitations."
		-John Waters