Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!cdr.utah.edu!moore From: moore%cdr.utah.edu@cs.utah.edu (Tim Moore) Newsgroups: comp.lang.lisp Subject: Re: Constants in code (Ex- Virtues of Lisp syntax) Message-ID: <1990Sep24.162735.13243@hellgate.utah.edu> Date: 24 Sep 90 22:27:35 GMT References: <2863191137@ARTEMIS.cam.nist.gov> Organization: University of Utah CS Dept Lines: 64 In article <2863191137@ARTEMIS.cam.nist.gov> miller@cam.nist.gov (Bruce R. Miller) writes: > >In article , David Vinayak Wallace writes: >> Date: 21 Sep 90 22:09:56 GMT >> From: miller@GEM.cam.nist.gov (Bruce R. Miller) >> Larry Masinter wrote: >> > (let ((var '(a b c))) >> > ... >> > (nconc var value)) >> ... >> Quote returns the object it was handed. It doesn't try to guess "what >> you meant." After all, the code isn't text; quote just has a pointer >> to the car of the list you handed it! >> >I'm a little confused about what you're saying. In the simplest case, >READ consed up the list, and QUOTE just returns its arg. >Clearly if you repeatedly INTERPRETED the above form, you get the same >result each time. (but perhaps not within a defun which may or may >not digest the form!) Regardless of any processing done by defun, the form is read only once. It is true that the cons cell that is the value of var is the same from invocation to invocation. However, the intention is that the last element of the list whose head is that cons cell will be changed each time through the code. So the result, (say, the return value of nconc) is different each time. >If you WANT the permanent change then you should presumably write >(let ((var '(a b c))) > (defun foo (..) > .. (nconc var value))) >to make clear the extent of var. This implies that foo is a closure. The previous code is an idiom that dates from Lisps without closures. You're still trying to modify a quoted constant here. If you have closures you might as well do (let ((var '(c b a))) (defun foo (...) (push value var))) >> Anyway, the capability to side-effect constants in storage was not >> removed for taste reasons, but efficiency; it permits me as a lisp >> implementor to place code into read-only storage (and possibly share >> it among processes). > >Ah, if it's in read-only storage then you can NOT modify it, no? If you want to modify it, don't quote it. > >BTW; Tim Moore, in another posting pointed out that this is considered >`illegal' although he didn't say if CLtL specified whether an error is >signalled or whether it is simply `undefined'. In the terminology of CLtL, "it is an error". This means that valid Common Lisp programs can't do it, but if it's done the results are undefined and an error need not be signalled. > >bruce Tim Moore moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore "Ah, youth. Ah, statute of limitations." -John Waters