From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Geoff Gole Newsgroups: gmane.emacs.bugs Subject: bug#6497: 6497 Date: Fri, 2 Jul 2010 09:39:38 +0800 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1278035984 23601 80.91.229.12 (2 Jul 2010 01:59:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 2 Jul 2010 01:59:44 +0000 (UTC) Cc: 6497@debbugs.gnu.org To: MON KEY Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 02 03:59:41 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OUVXY-0000iu-NK for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 Jul 2010 03:59:41 +0200 Original-Received: from localhost ([127.0.0.1]:39627 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OUVXY-00051V-3I for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Jul 2010 21:59:40 -0400 Original-Received: from [140.186.70.92] (port=43366 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OUVXR-00050t-K3 for bug-gnu-emacs@gnu.org; Thu, 01 Jul 2010 21:59:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OUVXQ-0005wB-EP for bug-gnu-emacs@gnu.org; Thu, 01 Jul 2010 21:59:33 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46364) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUVXQ-0005w3-B0 for bug-gnu-emacs@gnu.org; Thu, 01 Jul 2010 21:59:32 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OUVEZ-0008E8-AC; Thu, 01 Jul 2010 21:40:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Geoff Gole Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 02 Jul 2010 01:40:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6497 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6497-submit@debbugs.gnu.org id=B6497.127803478431615 (code B ref 6497); Fri, 02 Jul 2010 01:40:03 +0000 Original-Received: (at 6497) by debbugs.gnu.org; 2 Jul 2010 01:39:44 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUVEF-0008Ds-Dt for submit@debbugs.gnu.org; Thu, 01 Jul 2010 21:39:43 -0400 Original-Received: from mail-qy0-f179.google.com ([209.85.216.179]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUVEE-0008Dl-2s for 6497@debbugs.gnu.org; Thu, 01 Jul 2010 21:39:42 -0400 Original-Received: by qyk2 with SMTP id 2so145500qyk.3 for <6497@debbugs.gnu.org>; Thu, 01 Jul 2010 18:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yG/Zjmt07eLIJxtesgJ5prurhGhf/7Qh3IUKtSKmuPw=; b=jttu62o6myn8vZ1Vgl4mBnEntCaYByVTrkX/atFD4RnDmREsfnCHf2YiuFp+xhgGhl Xfk11wzdR+a+zNOCxmcH6d92HVL4jVy9KN+lV+kJVIVfo0drJFN0ro/KKgMJsY2j7/1h eG4eU1jFpon2M6ejqmOsUk6WIaIbl6yZBYP98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ArioE6i53YsJ1nEZfHRc/Mv90wxIYx6H+2/zIGiQVNbDpYCcp+e+u3bstMlC079UaF HkKP2kwDTPkDYYqp7xk4UxFJnOAiOUchBTg/Hg179tNDVS9cW/YeZFUsL2TeLuf3PW0j oxhA0Tz+BpE9aMN0N6VzikmYpriAxhcNEdIME= Original-Received: by 10.224.20.77 with SMTP id e13mr250052qab.109.1278034778126; Thu, 01 Jul 2010 18:39:38 -0700 (PDT) Original-Received: by 10.229.30.77 with HTTP; Thu, 1 Jul 2010 18:39:38 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Thu, 01 Jul 2010 21:40:03 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:38191 Archived-At: > When given an unquoted symbol as its argument `indirect-variable' will > return the value of a non-null symbol. That it does so represents a > subtle alteration of the generally expected semantics No it does not. The form (indirect-variable foo) is evaluated by fetching the value of the symbol foo and passing it to the function definition of indirect-variable, just like every other regular function in emacs. See (info "(elisp)Evaluation"). > Neither are regular lisp functions they are both primitives defined in > src/data.c Whether they are implemented in C or lisp is irrelevant. All regular functions have their arguments evaluated in the same way. > Except, that they don't always. which the docstring is in error. I guess I phrased that poorly. These functions always return the function definition, which is just a value and not guaranteed to be a callable function at all. The "function definition" is simply whatever lisp value happens to be in the function slot of said symbol: (progn (fset foo 3) (symbol-function foo)) =3D> 3 There is no restriction on the type of the value retrieved by symbol-function whatsoever. > Sure they rely on the details of the function representation: No, see above. > (symbol-function indirect-function) > =3D> (void-variable indirect-function) ;; <-- void-variable > (indirect-function not-a-real-function) > =3D> (void-variable not-a-real-function) ;; <-- void-variable > (indirect-function symbol-function) > =3D> (void-variable symbol-function) ;; <-- void-variable These results are all straightforward, predictable results of the lisp evaluation process. The only difficulty is that emacs lisp is a lisp-2, with separate namespaces for values and functions. Once you understand that evaluating the symbol 'symbol-function' fetches from the *value slot* of that symbol, while the function definition accessed by symbol-function (or by calling the function) resides in the *function slot*, you'll see that this is the expected behaviour. Again, see (info "(elisp)Evaluation"). > How do these primitives reach determination that the function cell of > `not-a-real-function' is void if they don't access som portion of the > representation denoting that symbol is function/variable? The primitives in question know about the C representation of *symbols*, in particular how to test whether a function slot is empty. They do not know or care about the representation of functions. Why don't you go and look at the C implementation of symbol-function and indirect-function and verify for yourself what is going on? > - See bug#6496 re autoload objects not appearing in "What is a > =A0function" node in manual. > > - See bug#6486 re `byte-code-function-p' requiring the user to cross > =A0reference 3x info nodes in order to conclude that its return value > =A0is as per `symbol-function'. Perhaps that documentation should be changed. Documentation bugs don't seem to get much attention, though. > `symbol-function' and `indirect-function' are the cannonical > interfaces by which one can access the function cell of a symbol. The documentation of symbol-function is fine. The function itself is a simple accessor that does nothing except fetch a value from the function slot of a symbol, and the docstring reflects that. > Really, symbol-function and his buddy `indirect-function' return: > > =A0- a lambda form > =A0- a vector > =A0- a list > =A0- a cons > =A0- and two types of unreadable objects They can return many more types of value than that. This is a natural result of the fairly large Emacs Lisp type zoo and nothing to do with the functions themselves.