From ... From: Erik Naggum Subject: Re: problem with delete Date: 2000/10/05 Message-ID: <3179724553025467@naggum.net>#1/1 X-Deja-AN: 677811574 References: <8r9vam$ie5$1@curofix.ida.liu.se> <3179481728635665@naggum.net> mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 970738889 4238 195.0.192.66 (5 Oct 2000 09:41:29 GMT) Organization: Naggum Software; vox: +47 800 35477; gsm: +47 93 256 360; fax: +47 93 270 868; http://naggum.no; http://naggum.net User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 Mime-Version: 1.0 NNTP-Posting-Date: 5 Oct 2000 09:41:29 GMT Newsgroups: comp.lang.lisp * tar@sevak.isi.edu (Thomas A. Russ) | Actually, it would seem to me that a conforming implementation could | return T and T for this example. There is no requirement that | REMOVE create a new list, just that it not modify the original list. Well, I asked you (or anyone) to explain why it _should_ return nil and t, not whether it _could_ return something else. | The hyperspec explicity says "The result of remove may share with | sequence". Of course the hyperspec also claims immediately before | that sentence "If any elements need to be removed, the result will | be a copy." In the case of all the removed elements being at the | front of the list that may not have really been the intention of the | committee to require a copy. Would you care to implement the remove that shares structure and compare it with one that does not share structure? I think this will be very illuminating. #:Erik -- If this is not what you expected, please alter your expectations.