From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Pascal J. Bourguignon" Newsgroups: gmane.emacs.help Subject: Re: Why doesn't nconc change my variable? Date: Sun, 05 Oct 2014 20:31:29 +0200 Organization: Informatimago Message-ID: <877g0emkqm.fsf@kuiper.lan.informatimago.com> References: <87y4svl2ku.fsf@wmi.amu.edu.pl> <3867d7c2-936d-4441-91d6-3b12dc959391@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1412534424 22231 80.91.229.3 (5 Oct 2014 18:40:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 Oct 2014 18:40:24 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Oct 05 20:40:19 2014 Return-path: Envelope-to: geh-help-gnu-emacs@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 1XaqjC-0002hH-LZ for geh-help-gnu-emacs@m.gmane.org; Sun, 05 Oct 2014 20:40:18 +0200 Original-Received: from localhost ([::1]:48349 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XaqjC-0007pE-1x for geh-help-gnu-emacs@m.gmane.org; Sun, 05 Oct 2014 14:40:18 -0400 Original-Path: usenet.stanford.edu!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 88 Original-X-Trace: individual.net e2tN1ISi4gqDakIBTTSyugfq8+cnhFHxseN0MR6hu/3LGF0E7R Cancel-Lock: sha1:NjNmYzYzMWEwYzM0Y2IwNjU0NzRmNmRiMGE0MGE0YjU0YjYzNmQ5Ng== sha1:pxMs2yXBtRx1NZ1XdNoQSUw0gi4= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Original-Xref: usenet.stanford.edu gnu.emacs.help:208017 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:100293 Archived-At: Marcin Borkowski writes: > (Now that I'm wondering what the implementation might actually be, I'm > more and more tempted to look at the C source. This is probably a good > sign.) Instead, look at the lisp source! ;-) (defun .nconc (&rest lists) (let ((lists (do ((curlists lists (rest lists))) ((or (null curlists) (first curlists)) curlists)))) (when lists (let ((current (first lists))) (dolist (next (rest lists) (when next (setf (cdr (last current)) next current next))))))) (.nconc (list 1 2 3) (list 4 5 6) (list 7 8 9)) --> (1 2 3 4 5 6 7 8 9) (.nconc (list 1 2 3) nil (list 4 5 6)) --> (1 2 3 4 5 6) (.nconc (list 1 2 3) nil) --> (1 2 3) (.nconc nil (list 1 2 3)) --> (1 2 3) (.nconc nil) --> nil > 1. Do I get it correctly that the "destructiveness" of some functions > (like nconc) does /not/ mean that they /change/ some of their arguments, > but only that they /may/ do it, and that relying on that is risky? Yes. > 2. Do I get it correctly that what Pascal called "a nil symbol" is just > NUL under the hood? No. > Does it mean that there's no difference between (), > nil and the result of (list) (as opposed to the results of calling list > twice with the same arguments)? (They seem to be `eq', as I've just > checked.) If they're eq then there's no difference. It's the lisp reader that reads () as nil: (car (read-from-string "()")) --> nil (car (read-from-string "nil")) --> nil (car (read-from-string "(list)")) --> (list) It's the lisp evaluator that calls list and have it return nil, just like nil, since nil is bound to nil: (symbol-value 'nil) --> nil (eval 'nil) --> nil (eval '(list)) --> nil > 3. What is the "canonical" way to append an element to a list, in the > sense that I have a variable containing (=pointing to?) a list, I want > it to point to a list one element longer? And, while at that, what is > the "canonical" way to /prepend/ an element to a list (is it `push'?) (setf list (nconc list (list new-element))) > 4. (This is the suggestion.) If the above is right, could someone make > it more clear in the manual (or point me to the place in the manual > where it is actually stated)? Your above was wrong, so no. ;-) I guess these things are explained more pedagogically in (info "(eintr)") and notably in (info "(eintr) List Implementation") -- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.” -- Carl Bass CEO Autodesk