Xref: utzoo comp.lang.lisp:3687 comp.lang.scheme:1702
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!julius.cs.uiuc.edu!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: <20692@well.sf.ca.us>
Date: 21 Sep 90 18:31:45 GMT
References: <10722@life.ai.mit.edu> <20501@well.sf.ca.us> <1990Sep18.180829.8801@hellgate.utah.edu>
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 68


Larry Masinter wrote:
>>>[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))
>>> ]

To which I replied:
>>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).

And Tim Moore wrote:

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

Tim is quite correct, and points out what I (now) assume Larry Masinter
meant.  I (mis-)took the example in a different context.

>>It's not legal Common
>>Lisp code, because the constant may be in read-only memory.

Correct me if I'm wrong, but it seems to me that this *is* legal and
that the compiler should specifically *not* allocate quoted lists such
as that to read-only memory!

In any case, it's basically poor programming style, which is found in
every language.

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

This assume a destructive replacement at the point of invocation of
these forms.  In the dark distant pass, macro expansion during
interpretation occured *every* time the form was encountered (and
COND wasn't a macro); one paid the price during interpretation, trading
off ease of debugging and  maintaining the original form for the improvement
in efficiency during compilation.  As time went on, destructive replacement
during interpretation became an option, and subsequently became the
de-facto default.  (Note that this provides its own set of problems,
i.e. a macro being changed, but previous invocations don't get updated).

But none of these arguments is particularly compelling, IMHO.  They
are throwing the baby out with the bath water, i.e. "because the
programmmer may have difficulty dealing with certain things in such
an environment, we will eliminate all such capabilities"!


>"Ah, youth.
I remember youth...
>Ah, statute of limitations."
Thank god!
>		-John Waters

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