Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bouma
From: bouma@cs.purdue.EDU (William J. Bouma)
Newsgroups: comp.lang.lisp
Subject: Re: Are "destructive" functions really destructive?
Summary: usually
Keywords: delete
Message-ID: <8769@medusa.cs.purdue.edu>
Date: 29 Nov 89 17:09:19 GMT
References: <20991@mimsy.umd.edu>
Distribution: usa
Organization: Department of Computer Science, Purdue University
Lines: 32

In article <20991@mimsy.umd.edu> folta@tove.umd.edu (Wayne Folta) writes:
>Is it thus true that I cannot count on destructive behavior when I want it?
>
>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?

    Destructive operations are not really any easier to implement. Rather
    they are faster and consume less memory than the identical but copying
    operations. Thus they benefit the user.

    Which reference are you quoting? It may be messed up! What good are
    destructive operations if they aren't truely destructive? Even in
    CLtL the wording is strange for this, "The argument SEQUENCE may be
    destroyed and used to construct the result;" (pg. 254, delete). Why
    does it say 'may' instead of 'will'? It could be just to account for
    the case when no element is deleted.

    Note that it is good practice to wrap your destructive operation
    in a 'setf' anyway. It usually isn't too difficult and can keep you
    from getting nailed by special cases you have overlooked. For instance
    what if the element you are deleting is the first one in the list?
    > (setq *b* '(a b c d))
    (A B C D)
    > (delete 'a *b*)
    (B C D)
    > *b*
    (A B C D)
    In this case, the resulting sequence is not EQ to the argument.
-- 
Bill <bouma@cs.purdue.edu>  ||  ...!purdue!bouma