From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: Side effects of `sort' Date: Thu, 01 Mar 2012 21:52:56 +0100 Message-ID: <87obsg3uxj.fsf@thinkpad.tsdh.de> References: <8762eoum93.fsf@schoepe.localhost> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1330635191 30205 80.91.229.3 (1 Mar 2012 20:53:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 1 Mar 2012 20:53:11 +0000 (UTC) Cc: emacs-devel@gnu.org To: Daniel Schoepe Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 01 21:53:10 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1S3Czt-00015s-Q4 for ged-emacs-devel@m.gmane.org; Thu, 01 Mar 2012 21:53:09 +0100 Original-Received: from localhost ([::1]:42047 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3Czt-0006wm-8n for ged-emacs-devel@m.gmane.org; Thu, 01 Mar 2012 15:53:09 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:39916) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3Czo-0006wR-RG for emacs-devel@gnu.org; Thu, 01 Mar 2012 15:53:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S3Czm-0006j4-Bn for emacs-devel@gnu.org; Thu, 01 Mar 2012 15:53:04 -0500 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]:36086) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3Czm-0006ig-3v for emacs-devel@gnu.org; Thu, 01 Mar 2012 15:53:02 -0500 Original-Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 532C921914 for ; Thu, 1 Mar 2012 15:53:00 -0500 (EST) Original-Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute4.internal (MEProxy); Thu, 01 Mar 2012 15:53:00 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=from:to:cc:subject:references:date :in-reply-to:message-id:mime-version:content-type; s=smtpout; bh=pTmensPbNlPxEpZU4NyMPIOpLEQ=; b=USpY2I6D2HUjt5BgG905NMrqt5Hg anS0i2dVW+6TUsql0FRNSbt9uPw9R9j2NPylywiYqmTcsLw7JnuH9xH+gzWrKAz/ Iw8E+JiLW8IWBjOZ7JhCV8aqB/pzLOjPswRRoIYuDwYVAe4Q6dobELN5YbVvbjGM BrFMssMHMV2DD9Q= X-Sasl-enc: qIoynWxNOPQTSk+ZHAUubB4LPbwV/tlt45jXPa8eIyFh 1330635179 Original-Received: from thinkpad.tsdh.de (91-67-11-43-dynip.superkabel.de [91.67.11.43]) by mail.messagingengine.com (Postfix) with ESMTPSA id 451DC4824CB; Thu, 1 Mar 2012 15:52:59 -0500 (EST) In-Reply-To: <8762eoum93.fsf@schoepe.localhost> (Daniel Schoepe's message of "Thu, 01 Mar 2012 20:58:16 +0100") User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 66.111.4.29 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:148867 Archived-At: Daniel Schoepe writes: Hi Daniel, > according to describe-function, `sort' modifies its input list, but > not in any way that the programmer can rely on. (For example, '(2 1 3) > becomes '(2 3)). I assume the precise thing that ends up in the > original list is an implementation detail and being able to "destroy" > the original list has some performance benefits. > > Personally, I find this behavior very surprising and think it would make > more sense to either set the input list to the final sorting result (in > addition to returning it) or not to modify the input. That's the point of all destructive operations like sort, nconc, nreverse and so forth. The perform better, because they don't copy but only rearrange pointers in their input, and you must always use the return value. In your example, foo points to the list (2 1 3), i.e., foo is a pointer to the cons cell (2 . cdr). foo -> (2 . (1 . (3 . nil))) 2 is bigger than 1, so we can make the 1-cons-cdr point to the 2-cons, and the 2-cons-cdr point to the cdr of the 1-cons. (1 . (2 . (3 . nil))) ^ | foo However, the variable foo still points to the original cons cell (2 . cdr). See? Bye, Tassilo