From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.help Subject: Re: obarray Date: Tue, 17 Dec 2013 03:55:59 +0100 Message-ID: <87haa8mbi8.fsf@web.de> References: <87haabq6gl.fsf@nl106-137-194.student.uu.se> <87bo0irj13.fsf@nl106-137-194.student.uu.se> <87wqj6pva0.fsf@nl106-137-194.student.uu.se> <87txeaxb4l.fsf@nl106-137-194.student.uu.se> <87r49cp6o5.fsf@nl106-137-194.student.uu.se> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1387248995 26348 80.91.229.3 (17 Dec 2013 02:56:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Dec 2013 02:56:35 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Dec 17 03:56:40 2013 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 1Vskps-0004Hl-0w for geh-help-gnu-emacs@m.gmane.org; Tue, 17 Dec 2013 03:56:40 +0100 Original-Received: from localhost ([::1]:59423 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vskpr-0005av-NB for geh-help-gnu-emacs@m.gmane.org; Mon, 16 Dec 2013 21:56:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49135) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vskpa-0005Zf-Fz for help-gnu-emacs@gnu.org; Mon, 16 Dec 2013 21:56:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VskpU-0002t2-LY for help-gnu-emacs@gnu.org; Mon, 16 Dec 2013 21:56:22 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:53393) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VskpU-0002su-Ef for help-gnu-emacs@gnu.org; Mon, 16 Dec 2013 21:56:16 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VskpS-0003zY-QG for help-gnu-emacs@gnu.org; Tue, 17 Dec 2013 03:56:14 +0100 Original-Received: from ip-90-186-227-169.web.vodafone.de ([90.186.227.169]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Dec 2013 03:56:14 +0100 Original-Received: from michael_heerdegen by ip-90-186-227-169.web.vodafone.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Dec 2013 03:56:14 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 66 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip-90-186-227-169.web.vodafone.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:YQii/qHBBHhp2fLT+hY9enzzEcM= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:95034 Archived-At: Emanuel Berg writes: > Yes, this much I understood, only it was hard to > visualize in practice. So: the macro accept code *as > arguments* (code that isn't evaluated) and transforms > that code? Exactly. Although, let's better say it accepts expressions (it must not be valid code as such), and transforms them into code without evaluating them before. For example: (dolist (i '(1 2 3)) (message "%s" i)) The expressions (i '(1 2 3)) and (message "%s" i) are "arguments" to the macro `dolist' in this call. These are not evaluated, but transformed into code. You can see the transformed code with `macroexpand': (macroexpand '(dolist (i '(1 2 3)) (message "%s" i))) ==> (cl--block-wrapper (catch '--cl-block-nil-- (let ((--dolist-tail-- '(1 2 3)) i) (while --dolist-tail-- (setq i (car --dolist-tail--)) (message "%s" i) (setq --dolist-tail-- (cdr --dolist-tail--)))))) A macro call with the above arguments will first generate (expand) the code to an expression like that, and will then execute it. In the above case, the macro expanded to code that introduces another variable, --cl-block-nil--. In our case, it's an interned (!) symbol. You can see why this isn't good when you try to evaluate (dolist (--dolist-tail-- '(1 2 3)) (message "%s" i)) Now you by coincidence use the symbol in the expression to be transformed that the macro introduces as new variable. They collide, and (dolist (--dolist-tail-- '(1 2 3)) (message "%s" i)) doesn't work when evaluated. So, it would be more correct to use an uninterned symbol instead of '--dolist-tail--, then such a collision could never happen. They used a quite exotic name for the symbol so such a collision is unlikely, but strictly speaking, the implementation of dolist is not correct. Defining `dolist' correctly is a good exercise for learning how to write macros. Regards, Michael.