Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cme!cam!ARTEMIS
From: miller@GEM.cam.nist.gov (Bruce R. Miller)
Newsgroups: comp.lang.lisp
Subject: Re: Virtues of Lisp syntax
Message-ID: <2862943796@ARTEMIS.cam.nist.gov>
Date: 21 Sep 90 22:09:56 GMT
References: <20692@well.sf.ca.us>
Sender: news@cam.nist.gov
Followup-To: comp.lang.lisp
Organization: NIST - Center for Computing and Applied Mathematics
Lines: 62


In article <20692@well.sf.ca.us>, Jeffrey Jacobs writes: 
> 
> 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 ...> 
> And Tim Moore wrote:
> >It is self-modifying code in the sense ...
> Tim is quite correct, and points out what I (now) assume Larry Masinter
> ...
> >>It's not legal Common Lisp code, because ...
> Correct me if I'm wrong, but it seems to me that this *is* legal and...
> In any case, it's basically poor programming style, which is found in
> every language.

That last point is RIGHT in any case.
Without digging thru  CLtL to  determine its  legality, it  seems pretty
clear that  it  is  unclear  what  it  SHOULD  do!  And  that  different
interpreters/compilers  will  make  different  choices.  And  that   the
Committee probably didn't even want to specify.

Having written such things  accidentally in the  past (most likely  on a
misguided optimization binge :>), and been, of course, severely bitten, I
was curious what Rel 8 symbolics  (on ivory) did.  Interpreted, it  does
permanently modify the data.  Compiled it gave an error to the effect:

Error: Attempt to RPLACD a list that is embedded in a structure and
       therefore cannot be RPLACD'ed.  

BRAVO! (and, to the best of my knowledge, they dont even have
read-only memory; or maybe ivory does now?)

In any  case,  one  could  imagine  a  perfectly legitimate interpretter
consing the list fresh  every time, giving  a 3rd behavior.   Before you
groan, consider that this might in fact be the most consistent behavior!
The (QUOTE (A B C)) form is (conceptually, at least) evaluated each time
the function is called!  Should (QUOTE (A B C)) sometimes 
return (A B C FOO)?

In any case, I suspect we've wandered off on a tangent here...

> >Rather, it's the macros that are a part of
> >the language that cause trouble. Consider how often Common Lisp

YOW! For my tastes (note that I said Taste!) the lisp macro may be the
single most dramatic and convincing feature in FAVOR of lisp!
[Not that I dont like its other features].

Some people argue that the lisp code/data equivalence is seldom used --
If they mean programs that explicitly build other programs, yes I write
relatively few of them.  BUT, the power & flexibility of macros comes
from being able to write macros almost exactly like writing any other
lisp.  And most lisp programmers I know, myself included, use macros
quite heavily.  Even when I use a continuation style (sort of), I
usually hide it in a cozy with-foo type macro.

bruce.