Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!wuarchive!decwrl!shelby!neon!michaelg From: michaelg@Neon.Stanford.EDU (Michael Greenwald) Newsgroups: comp.lang.lisp Subject: Re: Are "destructive" functions really destructive? Message-ID: <1989Nov29.173139.26165@Neon.Stanford.EDU> Date: 29 Nov 89 17:31:39 GMT References: <20991@mimsy.umd.edu> Sender: USENET News System Distribution: usa Organization: Computer Science Department, Stanford University Lines: 43 folta@tove.umd.edu (Wayne Folta) writes: >I take it from the Common LISP Reference that functions marked "(destructive)" >are destructive in the sense that they *may be* destructive in some way. >Is it thus true that I cannot count on destructive behavior when I want it? Yes. (I assume you mean by "count on" .. "when I want it" that identity of the argument would be preserved. It would be hard to "count on" some internal detail not specified by the language specification.) >For example, if I want to delete something from a large datastructure, I >assume that I would use "delete": > (delete item huge-list :key #'my-key) No. >Or do I need to do: > (setq huge-list (delete item huge-list :key #'my-key)) Yes. >In the Reference, it says, "..., or sequence may be unchanged and another >sequence returned.", which would seem to make "delete" different from "nconc" >in this respect. So destructiveness is an option for the convenience of LISP >implementation creators, not users? No, this behavior is dictated by the semantics of delete. To wit, (let ((x (copy-list '(a b c d e f)))) (setq y (delete 'a x))) There is no reasonable way to destructively "modify" x so that delete will work and you maitain EQness, since in this case DELETE == CDR. In other words, you lose the first cons cell, and the rest of the list is untouched. (I'm ignoring the pathological implementation of altering the CAR of every sublist, and knocking off the last cons.) >Wayne Folta (folta@cs.umd.edu 128.8.128.8)