From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: obarray Date: Tue, 17 Dec 2013 03:11:45 +0100 Organization: Aioe.org NNTP Server Message-ID: <87r49cp6o5.fsf@nl106-137-194.student.uu.se> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1387246513 3919 80.91.229.3 (17 Dec 2013 02:15:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Dec 2013 02:15:13 +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:15:19 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 1VskBq-0006JZ-NY for geh-help-gnu-emacs@m.gmane.org; Tue, 17 Dec 2013 03:15:18 +0100 Original-Received: from localhost ([::1]:59358 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VskBq-0005Md-3X for geh-help-gnu-emacs@m.gmane.org; Mon, 16 Dec 2013 21:15:18 -0500 Original-Path: usenet.stanford.edu!news.kjsl.com!feeder.erje.net!eu.feeder.erje.net!news.stack.nl!aioe.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 58 Original-NNTP-Posting-Host: VVbyYd/iFZoeWNmD9i++cQ.user.speranza.aioe.org Original-X-Complaints-To: abuse@aioe.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-Notice: Filtered by postfilter v. 0.8.2 Cancel-Lock: sha1:irPyNZeP4fjEPbUTANYct4il9sc= Mail-Copies-To: never Original-Xref: usenet.stanford.edu gnu.emacs.help:202763 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:95032 Archived-At: Michael Heerdegen writes: >> Is there a way to confirm this? How can I access a >> symbol's value, if the symbol isn't in the obarray? >> If it isn't in the obarray, where is it? Is there a >> buffer and/or "scope" (i.e. form or process) >> local/temporary object array or anything of the >> like? > > No. They are just existing in memory, and will not be > garage collected, as long as they can be referenced > from Lisp. There is also no array of all existing > strings, of all window configurations, etc. So you > can't tell Lisp to give you a complete list of all > currently existing strings, window configurations, or > (uninterned) symbols. There is just no need to > organize those objects in a user visible structure. OK. > OTOH, an uninterned symbol can be used like any other > symbol: it can be set, used to hold a function, etc. > >> You can access it the same way you can access the >> contents of arrays and lists -- by getting to it from >> some other variable (or cons cell or array element) >> that references it. That's what the variable >> uninterned-symbol is for. (symbol-value >> uninterned-symbol) => bar > > Of course, this is not very useful, it was just a > demonstration, not a realistic use case. Yes :) > When using uninterned symbols in macros, you can > "paste" these symbols in the expansion code which > will be evaluated at run-time. So, programs _can_ > contain uninterned symbols; you can really _use_ > uninterned symbols in code. Not in code read from a > file or buffer, but in code generated by macros. > This way, you avoid that you accidentally use a > symbol that is already "in use" (e.g. in the code the > macro transforms). 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? Then I get it. I thought the macro just produced new code, in what case I can't see how it could be useful because either no one knows about the macro so no one will use any symbols it may setup, *or* the macro knows about itself so any references to what is setup locally will be correct. -- Emanuel Berg, programmer-for-rent. CV, projects, etc at uXu underground experts united: http://user.it.uu.se/~embe8573