does sort always sort vectors in place?
in [Lisp]
|
From: Tamas K Papp on 25 Apr 2010 12:17 Does SORT always sort vectors in place? The HS says "The sorting operation can be destructive in all cases. In the case of a vector argument, this is accomplished by permuting the elements in place. In the case of a list, the list is destructively reordered in the same manner as for nreverse." It is unclear whether sorting vectors in place is an option ("can be ....") or it is always done that way. To put it differently, if V is known to be a vector, do I have to use (setf v (sort v predicate)) or can I just rely on (sort v predicate) to achieve the same effect? Thanks, Tamas
From: Pascal Costanza on 25 Apr 2010 12:32 On 25/04/2010 18:17, Tamas K Papp wrote: > Does SORT always sort vectors in place? The HS says > > "The sorting operation can be destructive in all cases. In the case of > a vector argument, this is accomplished by permuting the elements in > place. In the case of a list, the list is destructively reordered in > the same manner as for nreverse." > > It is unclear whether sorting vectors in place is an option ("can be > ...") or it is always done that way. To put it differently, if V is > known to be a vector, do I have to use > > (setf v (sort v predicate)) > > or can I just rely on > > (sort v predicate) > > to achieve the same effect? Yes, the latter. The wording "can be" seems to be a defense of the design choice to make sort destructive. The binding description is farther up in the spec, where it explicitly says that "sort and stable-sort destructively sort sequences". Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Peter Keller on 25 Apr 2010 13:34 Pascal Costanza <pc(a)p-cos.net> wrote: > On 25/04/2010 18:17, Tamas K Papp wrote: >> Does SORT always sort vectors in place? The HS says >> >> "The sorting operation can be destructive in all cases. In the case of >> a vector argument, this is accomplished by permuting the elements in >> place. In the case of a list, the list is destructively reordered in >> the same manner as for nreverse." >> >> It is unclear whether sorting vectors in place is an option ("can be >> ...") or it is always done that way. To put it differently, if V is >> known to be a vector, do I have to use >> >> (setf v (sort v predicate)) >> >> or can I just rely on >> >> (sort v predicate) >> >> to achieve the same effect? > > Yes, the latter. The wording "can be" seems to be a defense of the > design choice to make sort destructive. The binding description is > farther up in the spec, where it explicitly says that "sort and > stable-sort destructively sort sequences". I'm not sure I agree with this: From "Successful Lisp" by Lamkins: ----------------------- Places vs. values: destructive functions don't always have the desired side-effect A nondestructive function such as REVERSE always returns a freshly constructed result, so there's never any question but that you need to pay attention to the result. But a destructive function such as NREVERSE sometimes modifies its argument in such a way that the changed argument is identical to the function result. This leads some programmers to assume that destructive functions always modify the argument to match the result. Unfortunately, this is not true; leading to the second important point about the use of destructive functions: you should use the result of a destructive function the same way that you would use the result of its nondestructive counterpart. This also applies to SORT and STABLE-SORT, which are destructive and do not have a nondestructive counterpart. ----------------------- Since sort doesn't take a <place> like push or remf, you can't depend the side effect as having been correct. I'd say use (setf v (sort v predicate)) instead. Later, -pete
From: Pascal Costanza on 25 Apr 2010 14:31 On 25/04/2010 19:34, Peter Keller wrote: > Pascal Costanza<pc(a)p-cos.net> wrote: >> On 25/04/2010 18:17, Tamas K Papp wrote: >>> Does SORT always sort vectors in place? The HS says >>> >>> "The sorting operation can be destructive in all cases. In the case of >>> a vector argument, this is accomplished by permuting the elements in >>> place. In the case of a list, the list is destructively reordered in >>> the same manner as for nreverse." >>> >>> It is unclear whether sorting vectors in place is an option ("can be >>> ...") or it is always done that way. To put it differently, if V is >>> known to be a vector, do I have to use >>> >>> (setf v (sort v predicate)) >>> >>> or can I just rely on >>> >>> (sort v predicate) >>> >>> to achieve the same effect? >> >> Yes, the latter. The wording "can be" seems to be a defense of the >> design choice to make sort destructive. The binding description is >> farther up in the spec, where it explicitly says that "sort and >> stable-sort destructively sort sequences". > > I'm not sure I agree with this: > > From "Successful Lisp" by Lamkins: > > ----------------------- > Places vs. values: destructive functions don't always have the desired > side-effect > > A nondestructive function such as REVERSE always returns a freshly > constructed result, so there's never any question but that you need to > pay attention to the result. But a destructive function such as NREVERSE > sometimes modifies its argument in such a way that the changed argument > is identical to the function result. This leads some programmers to > assume that destructive functions always modify the argument to match the > result. Unfortunately, this is not true; leading to the second important > point about the use of destructive functions: you should use the result > of a destructive function the same way that you would use the result of > its nondestructive counterpart. > > This also applies to SORT and STABLE-SORT, which are destructive > and do not have a nondestructive counterpart. > ----------------------- > > Since sort doesn't take a<place> like push or remf, you can't depend the > side effect as having been correct. > > I'd say use > > (setf v (sort v predicate)) > > instead. Bleh, you're right... ;) Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: RG on 25 Apr 2010 15:09
In article <83jg3vFfn9U1(a)mid.individual.net>, Pascal Costanza <pc(a)p-cos.net> wrote: > On 25/04/2010 19:34, Peter Keller wrote: > > Pascal Costanza<pc(a)p-cos.net> wrote: > >> On 25/04/2010 18:17, Tamas K Papp wrote: > >>> Does SORT always sort vectors in place? The HS says > >>> > >>> "The sorting operation can be destructive in all cases. In the case of > >>> a vector argument, this is accomplished by permuting the elements in > >>> place. In the case of a list, the list is destructively reordered in > >>> the same manner as for nreverse." > >>> > >>> It is unclear whether sorting vectors in place is an option ("can be > >>> ...") or it is always done that way. To put it differently, if V is > >>> known to be a vector, do I have to use > >>> > >>> (setf v (sort v predicate)) > >>> > >>> or can I just rely on > >>> > >>> (sort v predicate) > >>> > >>> to achieve the same effect? > >> > >> Yes, the latter. The wording "can be" seems to be a defense of the > >> design choice to make sort destructive. The binding description is > >> farther up in the spec, where it explicitly says that "sort and > >> stable-sort destructively sort sequences". > > > > I'm not sure I agree with this: > > > > From "Successful Lisp" by Lamkins: > > > > ----------------------- > > Places vs. values: destructive functions don't always have the desired > > side-effect > > > > A nondestructive function such as REVERSE always returns a freshly > > constructed result, so there's never any question but that you need to > > pay attention to the result. But a destructive function such as NREVERSE > > sometimes modifies its argument in such a way that the changed argument > > is identical to the function result. This leads some programmers to > > assume that destructive functions always modify the argument to match the > > result. Unfortunately, this is not true; leading to the second important > > point about the use of destructive functions: you should use the result > > of a destructive function the same way that you would use the result of > > its nondestructive counterpart. > > > > This also applies to SORT and STABLE-SORT, which are destructive > > and do not have a nondestructive counterpart. > > ----------------------- > > > > Since sort doesn't take a<place> like push or remf, you can't depend the > > side effect as having been correct. > > > > I'd say use > > > > (setf v (sort v predicate)) > > > > instead. > > Bleh, you're right... ;) Even better: (defmacro sortf (place pred &rest args) `(setf ,place (sort ,place ,pred ,@args))) rg |