Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!orion.oac.uci.edu!uci-ics!schwamb
From: schwamb@ics.uci.edu (Karl Schwamb)
Newsgroups: comp.lang.lisp
Subject: Re: Are "destructive" functions really destructive?
Message-ID: <25742E50.28813@paris.ics.uci.edu>
Date: 29 Nov 89 19:30:23 GMT
References: <20991@mimsy.umd.edu> <Nov.29.13.25.49.1989.3378@busboys.rutgers.edu>
Distribution: usa
Lines: 38


I'm well aware of this problem with "delete" (that you need to setq a
variable upon returning in case its the first element of a list) in
using Lisp.  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:

> (setq string "123")
"123"
> (setq list '(1 2 3))
'(1 2 3)
> (delete #\1 string)
"23"
> string
"23"
> (delete 1 list)
'(2 3)
> list
'(1 2 3)

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.  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?


Karl B. Schwamb                                  schwamb@ics.uci.edu
Information and Computer Science                 
University of California, Irvine 92715