From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nicolas Richard Newsgroups: gmane.emacs.help Subject: Re: How does letf work? Date: Wed, 29 Jan 2014 16:06:27 +0100 Message-ID: <87txcmq13g.fsf@yahoo.fr> References: <52E838C8.5020101@miszellen.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1391008007 7649 80.91.229.3 (29 Jan 2014 15:06:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Jan 2014 15:06:47 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Jan 29 16:06:54 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 1W8Wj6-0004Jg-BB for geh-help-gnu-emacs@m.gmane.org; Wed, 29 Jan 2014 16:06:52 +0100 Original-Received: from localhost ([::1]:43168 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8Wj5-0002s1-SC for geh-help-gnu-emacs@m.gmane.org; Wed, 29 Jan 2014 10:06:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47498) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8Win-0002qQ-Fp for help-gnu-emacs@gnu.org; Wed, 29 Jan 2014 10:06:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W8Wie-000777-TU for help-gnu-emacs@gnu.org; Wed, 29 Jan 2014 10:06:33 -0500 Original-Received: from mxin.ulb.ac.be ([164.15.128.112]:12997) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8Wie-00076Y-Nc for help-gnu-emacs@gnu.org; Wed, 29 Jan 2014 10:06:24 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAHAY6VKkD4Xx/2dsb2JhbABZwRiBHXSCJQEBAQMBfgsIAyElDwEEDU+HcAEDCQirCZYIAUoNiBwXh3GEeYIcFoQiBJY8gWyGMYYthUGDLjs Original-Received: from mathsrv4.ulb.ac.be (HELO geodiff-mac3) ([164.15.133.241]) by smtp.ulb.ac.be with ESMTP; 29 Jan 2014 16:06:23 +0100 In-Reply-To: (Joost Kremers's message of "29 Jan 2014 08:37:45 GMT") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 164.15.128.112 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:95752 Archived-At: Joost Kremers writes: > I suspect what is going on is that what is returned by the letf (and > cl-letf) is not the value of the symbol test-x (which I've kinda assumed > up until now), but a pointer to the object test-x is referring to (i.e., > the first cons cell of the list). How I understand it is : what is returned by the letf *is* the value of the symbol, but since it is a cons cell it can be modified by setf (using setcar and setcdr). So part of the job of letf is to *change* the cons cell upon exiting. The box is the same (and is what is returned), but the content was changed at the moment the last closing paren of letf is crossed. IOW: (defvar test-x '(KEY 1 2 3 4)) (letf (((cdr test-x) '(a b c d))) (copy-sequence test-x)) => (KEY a b c d) but (copy-sequence (letf (((cdr test-x) '(a b c d))) test-x)) => (KEY 1 2 3 4) Returning (copy-sequence test-x) instead of test-x will produce the expected value. > And since the printing is done outside the letf, as you pointed out, the > object that's printed is the one pointed to by the global binding of > test-x. The object is the same, but its content changed. Similar to : (let ((foo (cons 'a 'b)) (bar)) (setq bar foo) ;; bar and foo have the same object in their value cell. (setcdr foo 'c) ;; change the cdr of that cons cell (eq bar foo)) ;; they're still the same. => t > But that's not because outside the letf the object created > inside it is necessarily gone. It's gone because letf doesn't return a > pointer to it I guess it's not gone per se until the garbage collector does its work. -- Nico.