home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / lisp / 2942 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  1.4 KB
  1. Xref: sparky comp.lang.lisp:2942 comp.lang.lisp.mcl:1672
  2. Newsgroups: comp.lang.lisp,comp.lang.lisp.mcl
  3. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!convex!news.oc.com!spssig.spss.com!uchinews!gargoyle.uchicago.edu!owens
  4. From: owens@gargoyle.uchicago.edu (Christopher Owens)
  5. Subject: Re: remove
  6. Message-ID: <owens.722538619@gargoyle.uchicago.edu>
  7. Sender: news@uchinews.uchicago.edu (News System)
  8. Organization: University of Chicago Computing Organizations
  9. References: <HALTRAET.92Nov20091121@monsun.si.no> <1992Nov23.161022.20210@mail.cornell.edu>
  10. Date: Mon, 23 Nov 1992 17:10:19 GMT
  11. Lines: 19
  12.  
  13. In <1992Nov23.161022.20210@mail.cornell.edu> Tim Larkin <tsl1@cornell.edu> writes:
  14.  
  15. > On the other hand, Common Lisp, the Manual, states that "the result [of 
  16. > remove] is a copy of the input sequence." If you return part of the 
  17. > original list, then you change the contract of the function. Sometimes 
  18. > one uses remove and requires a totally new list. One must be careful 
  19. > about "efficiency".
  20.  
  21. I was just about to post exactly this response until, in a stunning
  22. (for me) display of scholarship, I read a page further in the
  23. reference and discovered what seems to me like an inconsistency in the
  24. defined semantics of the function. (CLtL2, pg 400):
  25.  
  26.   "The result of REMOVE may share with the argument; a list result may
  27.    share a tail with an input list, and the result may be eq to the
  28.    input sequence if no elements need to be removed."
  29.  
  30.  
  31.  
  32.