Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!think!think.com!barmar From: barmar@think.com Newsgroups: comp.lang.lisp Subject: Re: Are "destructive" functions really destructive? Message-ID: <31810@news.Think.COM> Date: 29 Nov 89 21:29:03 GMT References: <20991@mimsy.umd.edu> <25742E50.28813@paris.ics.uci.edu> Sender: news@Think.COM Distribution: usa Organization: Thinking Machines Corporation, Cambridge MA Lines: 44 In article <25742E50.28813@paris.ics.uci.edu> schwamb@ics.uci.edu (Karl Schwamb) writes: >It seems cleaner to have (delete item sequence) expand to something >like (no, this doesn't do all the proper checking): > `(if (listp ,sequence) > (setf ,sequence > (CL-delete ,item ,sequence))) Lisp is a *functional* programming language, and the above is contrary to that philosophy. For instance, what happens when sequence isn't a place that can be SETFed? For instance, one might write code like: (setq result (delete item (append foo bar baz))) Or what if you didn't really need to store the result back into the variable the list came from, e.g. (let (other-list (*list* (compute-the-list))) (declare (special *list*)) (setq other-list (delete item *list*)) ) If nothing in references *list* then there is no need to store the result back there, since the value will bt thrown away when the LET returns. If *list* were a lexical variable then the compiler could discover that the store is unnecessary using live variable analysis, but since it's a special variable this is not always feasible. If you want a DELETEF macro, create one. This would be just like the distinction between 1+ and INCF. If you think DELETEF should have been included in the standard language as INCF was, that's a completely different issue. I suspect it wasn't because then the language would have had to have SETF-like versions of all the destructive sequence operations. Maclisp and Zetalisp, the primary influences on Common Lisp, had INCF, so it was kept, but the CL designers apparently didn't want to throw in a zillion new macros of that type. Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar