home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / lisp / 2901 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  1.5 KB
  1. Path: sparky!uunet!think.com!barmar
  2. From: barmar@think.com (Barry Margolin)
  3. Newsgroups: comp.lang.lisp
  4. Subject: Re: Lucid bug in delete-if?
  5. Date: 18 Nov 1992 08:44:43 GMT
  6. Organization: Thinking Machines Corporation, Cambridge MA, USA
  7. Lines: 24
  8. Message-ID: <1ecvprINNe6l@early-bird.think.com>
  9. References: <1992Nov14.180229.7728@cs.cornell.edu> <1992Nov14.205620.11328@news2.cis.umn.edu> <KRULWICH.92Nov16104949@zowie.ils.nwu.edu>
  10. NNTP-Posting-Host: gandalf.think.com
  11.  
  12. In article <KRULWICH.92Nov16104949@zowie.ils.nwu.edu> krulwich@zowie.ils.nwu.edu (Bruce Krulwich) writes:
  13. >Have any implementations ever tried to handle destructive modification of the
  14. >first element of a list by RPLACA'ing the first cons cell to the first element
  15. >of the desired list?
  16.  
  17. I've never heard of anyone doing it, although it's allowed.
  18.  
  19. >(Not that this would completely obviate the need to SETF the result of a
  20. >destructive operation, but I was just curious.)
  21.  
  22. Since it doesn't solve the problem (you still have to do the assignment if
  23. the result of the modification is NIL), there's not much point in doing it
  24. this way.  It's less efficient, because you have to do a RPLACA *and* a
  25. RPLACD whenever the CAR matches; and unless you're extra tricky, you'll
  26. also end up doing an extra CDDR to get the value to RPLACD.  This also
  27. requires the CAR to be handled as a special case, otherwise you'll get this
  28. expense for every matching element.
  29.  
  30.  
  31. -- 
  32. Barry Margolin
  33. System Manager, Thinking Machines Corp.
  34.  
  35. barmar@think.com          {uunet,harvard}!think!barmar
  36.