Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!samsung!uunet!lll-winken!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.205750.6530@Neon.Stanford.EDU> Date: 29 Nov 89 20:57:50 GMT References: <20991@mimsy.umd.edu> <25742E50.28813@paris.ics.uci.edu> Sender: USENET News System Distribution: usa Organization: Computer Science Department, Stanford University Lines: 48 schwamb@ics.uci.edu (Karl Schwamb) writes: >.... However, I don't understand why "delete" was not >implemented as a macro to make the semantics of its destructive >operation consistent. To have a function which applies to different >sequence types but performs differently for one implementation seems >bogus to me: If you always use delete for value, rather than for effect, then it always behaves consistently. >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))) >Where "CL-delete" would be the current CL delete function. By the way, your implementation doesn't work when sequence is the result of function application. It is illegal to "apply" (if such terminology is appropriate for a macro) SETF to something that isn't a "place". Or is this one of the things you were referring to when you said "this doesn't do all the proper checking"? >Of course, >if the types are known at compile-time then we can even remove the >check. Is this a case where upward compatibility has ruined the >elegance of the language standard? I don't think so. CL-delete doesn't side-effect the environment, while your macroized delete does. Yes, CL-delete does side-effect sequence (and if sequence is shared, and isn't just an intermediate result, then the side-effect is visible in the "environment"), but if delete is always used "functionally" (for value) you can argue convincingly that cl-delete is cleaner than your delete (if you subscribe to the notion, as many do, that side-effects aren't particularly clean, and therefore should be minimized). Reasonable people might differ about whether CL-delete is cleaner than your macroized delete (I strongly prefer CL-delete), but I don't think this is "a case where upward compatibility has ruined the elegance of the language standard"