From unknown Wed Jun 18 23:08:23 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#6497 <6497@debbugs.gnu.org> To: bug#6497 <6497@debbugs.gnu.org> Subject: Status: documentation `indirect-function', `symbol-function' do not enumerate return value type Reply-To: bug#6497 <6497@debbugs.gnu.org> Date: Thu, 19 Jun 2025 06:08:23 +0000 retitle 6497 documentation `indirect-function', `symbol-function' do not en= umerate return value type reassign 6497 emacs submitter 6497 MON KEY severity 6497 minor tag 6497 wontfix thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 22 19:43:07 2010 Received: (at submit) by debbugs.gnu.org; 22 Jun 2010 23:43:07 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ORD7S-0003qR-VF for submit@debbugs.gnu.org; Tue, 22 Jun 2010 19:43:07 -0400 Received: from mx10.gnu.org ([199.232.76.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ORD7Q-0003q5-Oy for submit@debbugs.gnu.org; Tue, 22 Jun 2010 19:43:05 -0400 Received: from lists.gnu.org ([199.232.76.165]:50773) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1ORD7M-0001ZE-Tc for submit@debbugs.gnu.org; Tue, 22 Jun 2010 19:43:00 -0400 Received: from [140.186.70.92] (port=51685 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ORD7L-00028G-OI for bug-gnu-emacs@gnu.org; Tue, 22 Jun 2010 19:43:00 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=unavailable version=3.3.1 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ORD7K-00019D-HG for bug-gnu-emacs@gnu.org; Tue, 22 Jun 2010 19:42:59 -0400 Received: from mail-yw0-f192.google.com ([209.85.211.192]:52737) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ORD7K-000197-Eu for bug-gnu-emacs@gnu.org; Tue, 22 Jun 2010 19:42:58 -0400 Received: by ywh30 with SMTP id 30so4524258ywh.24 for ; Tue, 22 Jun 2010 16:42:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.94.1 with SMTP id w1mr7100586ybl.72.1277250177242; Tue, 22 Jun 2010 16:42:57 -0700 (PDT) Received: by 10.150.181.11 with HTTP; Tue, 22 Jun 2010 16:42:57 -0700 (PDT) Date: Tue, 22 Jun 2010 19:42:57 -0400 X-Google-Sender-Auth: yId8E5fMr2OBhG9rmbopuJxlYtw Message-ID: Subject: documentation `indirect-function', `symbol-function' do not enumerate return value type From: MON KEY To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -3.8 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.1 (-----) documentation of function `indirect-function' and `symbol-function' do not adequately enumerate all of the types of return values (nor does it even make mention of them) and docstring of `indirect-function' too closeley mirrors that of `indirect-variable'. Additionally, the value of its argument OBJECT does not reflect that of the `symbol-function' arg SYMBOL it should because its return value more closely resembles that of `symbol-function' than `indirect-variable'. ,---- (documentation 'indirect-variable) | | Return the variable at the end of OBJECT's variable chain. | If OBJECT is a symbol, follow all variable indirections and return the | final variable. If OBJECT is not a symbol, just return it. Signal a | cyclic-variable-indirection error if there is a loop in the variable | chain of symbols. | | (fn OBJECT) | `---- ,---- (documentation 'indirect-function) | | Return the function at the end of OBJECT's function chain. | If OBJECT is not a symbol, just return it. Otherwise, follow all | function indirections to find the final function binding and return | it. If the final symbol in the chain is unbound, signal a | void-function error. Optional arg NOERROR non-nil means to return nil | instead of signalling. Signal a cyclic-function-indirection error if | there is a loop in the function chain of symbols. | | (fn OBJECT &optional NOERROR) | `---- ,---- (documentation 'symbol-function) | | Return SYMBOL's function definition. Error if that is void. | | (fn SYMBOL) | `---- Given the similarity of docstrings for `indirect-variable' and `indirect-function' it is possible for a user to assume the quoting rules of `indirect-variable' apply as well to `indirect-function'. In the following example `indirect-variable' returns regardless of whether the arg OBJECT is quoted: (indirect-variable font-lock-comment-face) (indirect-variable 'font-lock-comment-face) Whereas, in the following evaluation of `indirect-function' the first use of an arg as unquoted symbol signals an error. (indirect-function lisp-mode-variables) (indirect-function 'lisp-mode-variables) This problem isn't an issue were it not for the close resemblance of the `indirect-function' `indirect-variable' docstrings. More troublesome though is that neither `indirect-function' nor `symbol-function' document their return values in any meaningful way: Following is an attempt at fleshing out those return values not specified by the existing docstrings (substitute OBJECT for SYMBOL accordingly): ,---- | | If OBJECT satisfies the predicate `subrp' return an unreadable | object of the form: | | # | | If OBJECT is an "autuload object" type its return value is a list of | values suitable for use as arguments to the `autoload' function and | of the form: | | (autoload "" ) | | Note, the element for OBJECT's return value as "autoload | object" is nil for a function and `macro' or `t' for a macro. | | If value of OBJECT is a "byte-code function" type, e.g. it would | satisfy the predicate `byte-code-function-p', and OBJECT is not a | "Lisp macro" its value is returned as an unreadable vector of the | form: | | #[ ... ] | | if OBJECT is a "Lisp macro" in it value is returned as a cons of the | form: | | (macro . #[ ... ]) | `---- -- /s_P\ From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 01 05:20:31 2010 Received: (at 6497) by debbugs.gnu.org; 1 Jul 2010 09:20:31 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUFwd-0000fw-6x for submit@debbugs.gnu.org; Thu, 01 Jul 2010 05:20:31 -0400 Received: from mail-vw0-f44.google.com ([209.85.212.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUFwb-0000fr-8g for 6497@debbugs.gnu.org; Thu, 01 Jul 2010 05:20:29 -0400 Received: by vws14 with SMTP id 14so462309vws.3 for <6497@debbugs.gnu.org>; Thu, 01 Jul 2010 02:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=Sy3G7QBZE2jbTYNxdb35d+l1Yp4qw8H0s4oJjBVeRzY=; b=DUCiHKbasp84p6KYZdoA9JTc40M5+xes+Bvv1az7siAu8gcrGi67fV5iQJLReV2DE/ IJR80nWTysxi953dEYvjkLmZ91dqwGWJ3eQq5GCG5O9Fxms8fT7wbNcC7yUTD+kjkbhh M6Oatyc3dUCGhsZXsOOG5dSks41GQzzGF/2Ag= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=cEwE76p/tk6lwDMMcbvpbASHcwnAG+KfDAoyEn5FcqrJJvK4dainAFwEjTSAexvjpG doQUCZTXZx8KEArZZ8Ib/QZ+tBMk7OaUp9EwXOmBYs+7AWpnrgZakLzH1iMsFQIvCvHm pPs6c7ZlUKGmJNTbYW0IMbBdM4HeWAZJ93SoA= MIME-Version: 1.0 Received: by 10.229.223.194 with SMTP id il2mr5893368qcb.281.1277976026008; Thu, 01 Jul 2010 02:20:26 -0700 (PDT) Received: by 10.229.30.77 with HTTP; Thu, 1 Jul 2010 02:20:25 -0700 (PDT) Date: Thu, 1 Jul 2010 17:20:25 +0800 Message-ID: Subject: 6497 From: Geoff Gole To: monkey@sandpframing.com, 6497@debbugs.gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 6497 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.2 (--) > Given the similarity of docstrings for `indirect-variable' and > `indirect-function' it is possible for a user to assume the quoting > rules of `indirect-variable' apply as well to `indirect-function'. There are no "quoting rules" for indirect-variable or indirect-function. They are regular functions and have the same argument evaluation semantics as every other regular function. > More troublesome though is that neither `indirect-function' nor > `symbol-function' document their return values in any meaningful way: They mention that they return a "function definition", which is appropriately abstract given that these functions don't depend in any way on the details of function representation. Function values are already documented in detail elsewhere, and duplicating that documentation would not be helpful. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 01 20:21:11 2010 Received: (at 6497) by debbugs.gnu.org; 2 Jul 2010 00:21:11 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUU0E-0007kG-S2 for submit@debbugs.gnu.org; Thu, 01 Jul 2010 20:21:11 -0400 Received: from mail-gy0-f172.google.com ([209.85.160.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUU0C-0007kB-Am for 6497@debbugs.gnu.org; Thu, 01 Jul 2010 20:21:08 -0400 Received: by gyh3 with SMTP id 3so1395260gyh.3 for <6497@debbugs.gnu.org>; Thu, 01 Jul 2010 17:21:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.26.33 with SMTP id d33mr285355anj.140.1278029598595; Thu, 01 Jul 2010 17:13:18 -0700 (PDT) Received: by 10.151.46.4 with HTTP; Thu, 1 Jul 2010 17:13:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Jul 2010 20:13:18 -0400 X-Google-Sender-Auth: R8lqWimk1z25A7-Zw7Wte6cs488 Message-ID: Subject: Re: 6497 From: MON KEY To: Geoff Gole Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 6497 Cc: 6497@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.1 (---) On Thu, Jul 1, 2010 at 5:20 AM, Geoff Gole wrote: > Given the similarity of docstrings for `indirect-variable' and > `indirect-function' it is possible for a user to assume the quoting > rules of `indirect-variable' apply as well to `indirect-function'. >> There are no "quoting rules" for indirect-variable or 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 e.g. wheras `indirect-function' does signal an error. >> indirect-function. They are regular functions and have the same >> argument evaluation semantics as every other regular function. Neither are regular lisp functions they are both primitives defined in src/data.c (symbol-function 'indirect-function) (symbol-function 'indirect-variable) > More troublesome though is that neither `indirect-function' nor > `symbol-function' document their return values in any meaningful way: >> They mention that they return a "function definition", Except, that they don't always. which the docstring is in error. >> which is appropriately abstract Appropriately abstract for whom? >> given that these functions don't depend in any way on the details >> of function representation. Sure they rely on the details of the function representation: (symbol-function 'not-a-real-function) => (void-function not-a-real-function) (symbol-functiol not-a-real-function) => (void-function symbol-functiol) (symbol-function indirect-function) => (void-variable indirect-function) ;; <-- void-variable (indirect-function 'not-a-real-function) => (void-function not-a-real-function) (indirect-function not-a-real-function) => (void-variable not-a-real-function) ;; <-- void-variable (indirect-function symbol-function) => (void-variable symbol-function) ;; <-- void-variable 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? >> Function values are already documented in detail elsewhere, and In detail and across a wide range. e.g.: - See bug#6496 re autoload objects not appearing in "What is a function" node in manual. - See bug#6486 re `byte-code-function-p' requiring the user to cross reference 3x info nodes in order to conclude that its return value is as per `symbol-function'. >> duplicating that documentation would not be helpful. Would not be helful for whom? `symbol-function' and `indirect-function' are the cannonical interfaces by which one can access the function cell of a symbol. The docstring of `symbol-function' is a terse one sentence and doesn't provide any indication that the _readability_ of its return value varies significantly acording to the type of function given as the arugment. Really, symbol-function and his buddy `indirect-function' return: - a lambda form - a vector - a list - a cons - and two types of unreadable objects I would suggest this is is abnormal compared w/ the vast majority of Emacs lisp functions' return values. -- /s_P\ From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 01 21:39:43 2010 Received: (at 6497) by debbugs.gnu.org; 2 Jul 2010 01:39:44 +0000 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 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 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= MIME-Version: 1.0 Received: by 10.224.20.77 with SMTP id e13mr250052qab.109.1278034778126; Thu, 01 Jul 2010 18:39:38 -0700 (PDT) Received: by 10.229.30.77 with HTTP; Thu, 1 Jul 2010 18:39:38 -0700 (PDT) In-Reply-To: References: Date: Fri, 2 Jul 2010 09:39:38 +0800 Message-ID: Subject: Re: 6497 From: Geoff Gole To: MON KEY Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.9 (/) X-Debbugs-Envelope-To: 6497 Cc: 6497@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 03 00:27:42 2010 Received: (at 6497) by debbugs.gnu.org; 3 Jul 2010 04:27:42 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUuKL-0003GJ-Mo for submit@debbugs.gnu.org; Sat, 03 Jul 2010 00:27:41 -0400 Received: from mail-gw0-f44.google.com ([74.125.83.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUuKJ-0003GE-8L for 6497@debbugs.gnu.org; Sat, 03 Jul 2010 00:27:39 -0400 Received: by gwb10 with SMTP id 10so1954100gwb.3 for <6497@debbugs.gnu.org>; Fri, 02 Jul 2010 21:27:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.244.5 with SMTP id r5mr2036570anh.95.1278131255562; Fri, 02 Jul 2010 21:27:35 -0700 (PDT) Received: by 10.151.46.4 with HTTP; Fri, 2 Jul 2010 21:27:35 -0700 (PDT) In-Reply-To: References: Date: Sat, 3 Jul 2010 00:27:35 -0400 X-Google-Sender-Auth: GDQ7W-QJnZpyYBpnbCBcBMSb7v8 Message-ID: Subject: Re: 6497 From: MON KEY To: Geoff Gole Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 6497 Cc: 6497@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.2 (---) >> 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. Except it doesn't, as indicated by following pathology: (setq foo (unintern (makunbound 'foo))) (indirect-variable foo) `foo' should evaluate to t per return value of `unintern'. >> 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. If all regular functions have their arguments evaluated in the same way it is tautological to identify them by virtue of their property of regularity. Are you saying that unless a function is a special-operator its arguments are evaluated in an identical manner as any other non special-operator? > 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)) => 3 The previous form is twice in error. Which FWIW, I fail to find particularly humorous given the implied pedantry of your example. Prob. what you meant to was: (progn (fset 'foo 3) (symbol-function 'foo)) ;=> 3 Which is all well and good except that, (progn (unintern 'foo) (fset 'foo (indirect-function 'indirect-function)) (symbol-function 'foo)) ;=> # following should evaluate to `#' but won't. (indirect-function 'foo) ;=> (void-function foo) > There is no restriction on the type of the value retrieved by > symbol-function whatsoever. Sure there is, see error retrieved when fetching value of `foo' above. > 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 You've missed my point. The distinction between value cell and function cell confirms a reliance on the details of function representation. I was responding apropos your assertion: ,---- | given that these functions don't depend in any way on the details of | function representation. `---- > 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? I have, though one should not be required to examine src/lisp.h and src/data.c in order to make sense of them and besides "what is going on" inside data.c has little to do with the subject of this bug report, e.g. deficient documentation _of_ the implementation and not _the_ implementation itself. -- /s_P\ From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 03 02:31:41 2010 Received: (at 6497) by debbugs.gnu.org; 3 Jul 2010 06:31:41 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUwGK-0003z3-Pn for submit@debbugs.gnu.org; Sat, 03 Jul 2010 02:31:40 -0400 Received: from mail-pz0-f44.google.com ([209.85.210.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUwGI-0003yy-FS for 6497@debbugs.gnu.org; Sat, 03 Jul 2010 02:31:39 -0400 Received: by pzk36 with SMTP id 36so615979pzk.3 for <6497@debbugs.gnu.org>; Fri, 02 Jul 2010 23:31:34 -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:content-type; bh=hnvVUGlYxV/fl9fGagle4xpvI6DqQVOz7OJ5RCrMKzs=; b=TP7qzyiG6YNbDklN2ixPe4SF300vHBa0QfzXTK7Jz/jktWNtmik74TeME4I99qeUKx BDsCd2KbtCS9Tbr0mtTK6TOKADlstdG7m38OgD94i/eXYYBcTeW2ysd7NWfR5pyrK7Ce Mwv79lteNa/yV4S6ypkvSNvGlnv0eIdeg9kYY= 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 :content-type; b=MKJIEx8Bt7RwKwlffzLZCoUgYgt7oFi8oXCbfVLSLO4P8IN1/zchRsRCUDRUiOiSZy S3sA6CjCiv07ppxzixc1MFThp9HkiUyd3IquVYDiZ0a8MxXGpp40Ji0ogzDZgY70YVBA edUZ4eUyw7Piw5GxJe74x+0Vxv9DCcu5/A/nU= MIME-Version: 1.0 Received: by 10.142.170.2 with SMTP id s2mr2261673wfe.241.1278138694798; Fri, 02 Jul 2010 23:31:34 -0700 (PDT) Received: by 10.142.163.4 with HTTP; Fri, 2 Jul 2010 23:31:34 -0700 (PDT) In-Reply-To: References: Date: Sat, 3 Jul 2010 14:31:34 +0800 Message-ID: Subject: Re: 6497 From: Geoff Gole To: MON KEY , 6497@debbugs.gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 6497 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.2 (--) > Prob. what you meant to was: > (progn > (fset 'foo 3) > (symbol-function 'foo)) Indeed, although it's a trivial mistake. The example works just as well when the value of foo is a symbol, which it must have been at the time I tried it. > Unintern does funny things. Those funny things are not relevant to this bug report. > The distinction between value cell and > function cell confirms a reliance on the details of function > representation. What a bizarre claim. The number of slots in a symbol has nothing to do with the representation of functions. Why would it? From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 03 03:00:05 2010 Received: (at 6497) by debbugs.gnu.org; 3 Jul 2010 07:00:05 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUwho-0004BY-Ln for submit@debbugs.gnu.org; Sat, 03 Jul 2010 03:00:04 -0400 Received: from mail-out.m-online.net ([212.18.0.9]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUwhm-0004Au-BL for 6497@debbugs.gnu.org; Sat, 03 Jul 2010 03:00:03 -0400 Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 9D78F1C159FF; Sat, 3 Jul 2010 08:59:58 +0200 (CEST) X-Auth-Info: i7tnUZHafMKWQkYdYFOoxpIux1deG1bxiegp4sgf0o8= Received: from whitebox.home (ppp-88-217-127-253.dynamic.mnet-online.de [88.217.127.253]) by mail.mnet-online.de (Postfix) with ESMTPA id 4AC9B1C0017E; Sat, 3 Jul 2010 08:59:58 +0200 (CEST) Received: by whitebox.home (Postfix, from userid 501) id 5F5921E607E; Sat, 3 Jul 2010 09:00:12 +0200 (CEST) From: Andreas Schwab To: MON KEY Subject: Re: bug#6497: 6497 References: X-Yow: Here is my refrigerator full of FLANK STEAK...and over there is my UPHOLSTERED CANOE...I don't know WHY I OWN them!! Date: Sat, 03 Jul 2010 09:00:11 +0200 In-Reply-To: (MON KEY's message of "Sat, 3 Jul 2010 00:27:35 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 6497 Cc: 6497@debbugs.gnu.org, Geoff Gole X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) MON KEY writes: > Except it doesn't, as indicated by following pathology: > > (setq foo (unintern (makunbound 'foo))) > (indirect-variable foo) > > `foo' should evaluate to t per return value of `unintern'. The foos in the two lines are completely unrelated. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 03 15:34:05 2010 Received: (at 6497) by debbugs.gnu.org; 3 Jul 2010 19:34:05 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OV8TV-0001VN-2b for submit@debbugs.gnu.org; Sat, 03 Jul 2010 15:34:05 -0400 Received: from mail-gx0-f172.google.com ([209.85.161.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OV8TT-0001V1-Al for 6497@debbugs.gnu.org; Sat, 03 Jul 2010 15:34:03 -0400 Received: by gxk3 with SMTP id 3so303163gxk.3 for <6497@debbugs.gnu.org>; Sat, 03 Jul 2010 12:33:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.65.9 with SMTP id n9mr1164340aga.74.1278185638676; Sat, 03 Jul 2010 12:33:58 -0700 (PDT) Received: by 10.151.46.4 with HTTP; Sat, 3 Jul 2010 12:33:58 -0700 (PDT) In-Reply-To: References: Date: Sat, 3 Jul 2010 15:33:58 -0400 X-Google-Sender-Auth: Zedv-IyvcTp_37OT-VPTksXceh4 Message-ID: Subject: Re: bug#6497: 6497 From: MON KEY To: Andreas Schwab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 6497 Cc: 6497@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) On Sat, Jul 3, 2010 at 3:00 AM, Andreas Schwab wrot= e: > MON KEY writes: > >> Except it doesn't, as indicated by following pathology: >> >> =C2=A0(setq foo (unintern (makunbound 'foo))) >> =C2=A0(indirect-variable foo) >> >> `foo' should evaluate to t per return value of `unintern'. > > The foos in the two lines are completely unrelated. > Yep. The "first" foo is made unbound. The "first" foo is uninterned which returns `t'. The "second" foo is bound to the return value of uninterning the "first" foo e.g. `t'. That was not the point of the illustration. This was: The evaluation of the indirect-variable for the "second" foo should return = `t'. In the following, we change the "first" foo to a `tbar' there is no "second" foo and we `set' tbar instead of `setq'ing foo and this form does return `t': (unwind-protect (progn (unintern 'foo) (unintern 'tbar)) (let ((tbar (make-symbol "foo") )) (set 'tbar (unintern (makunbound 'foo))) (indirect-variable tbar))) ; =3D> t > Andreas. -- /s_P\ From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 03 15:35:35 2010 Received: (at 6497) by debbugs.gnu.org; 3 Jul 2010 19:35:35 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OV8Uw-0001WD-Bx for submit@debbugs.gnu.org; Sat, 03 Jul 2010 15:35:34 -0400 Received: from mail-gx0-f172.google.com ([209.85.161.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OV8Uv-0001W8-3j for 6497@debbugs.gnu.org; Sat, 03 Jul 2010 15:35:33 -0400 Received: by gxk3 with SMTP id 3so303523gxk.3 for <6497@debbugs.gnu.org>; Sat, 03 Jul 2010 12:35:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.67.8 with SMTP id p8mr1140647aga.53.1278185728658; Sat, 03 Jul 2010 12:35:28 -0700 (PDT) Received: by 10.151.46.4 with HTTP; Sat, 3 Jul 2010 12:35:28 -0700 (PDT) In-Reply-To: References: Date: Sat, 3 Jul 2010 15:35:28 -0400 X-Google-Sender-Auth: n9heb8X3O4y4iWqh05wzriTriak Message-ID: Subject: Re: 6497 From: MON KEY To: 6497@debbugs.gnu.org Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 6497 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) On Sat, Jul 3, 2010 at 2:31 AM, Geoff Gole wrote: >> Prob. what you meant to was: >> (progn >> (fset 'foo 3) >> (symbol-function 'foo)) > > Indeed, although it's a trivial mistake. The example works just as > well when the value of foo is a symbol, which it must have been at the > time I tried it. > The triviality of the mistake is apropos my rationale for requesting that the docstrings be further fleshed out, it is all to easy to find oneself in these sorts of situations w/re `symbol-function' & `indirect-function' and no way to reasonably partition an expected return value(s) from an unexpected one... That you fell pey to it while trying to illustrate a counter argument to my proposal is (in some small way) an indicative of the problem. > Unintern does funny things. Those funny things are not relevant to > this bug report. See above. > >> The distinction between value cell and >> function cell confirms a reliance on the details of function >> representation. > > What a bizarre claim. The number of slots in a symbol has nothing to > do with the representation of functions. Why would it? > If the symbol did not have cells it would. Which the "bizarre" behaviour of the unintern/makunbound examples illustrate. -- /s_P\ From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 03 15:47:49 2010 Received: (at 6497) by debbugs.gnu.org; 3 Jul 2010 19:47:49 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OV8gm-0001cK-Nc for submit@debbugs.gnu.org; Sat, 03 Jul 2010 15:47:48 -0400 Received: from mail-out.m-online.net ([212.18.0.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OV8gk-0001cE-35 for 6497@debbugs.gnu.org; Sat, 03 Jul 2010 15:47:46 -0400 Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id D7C881C00208; Sat, 3 Jul 2010 21:47:40 +0200 (CEST) Received: from igel.home (ppp-88-217-127-253.dynamic.mnet-online.de [88.217.127.253]) by mail.mnet-online.de (Postfix) with ESMTP id AC6C01C0032A; Sat, 3 Jul 2010 21:47:40 +0200 (CEST) Received: by igel.home (Postfix, from userid 501) id 85135CA297; Sat, 3 Jul 2010 21:47:40 +0200 (CEST) From: Andreas Schwab To: MON KEY Subject: Re: bug#6497: 6497 References: X-Yow: Hmmm.. a CRIPPLED ACCOUNTANT with a FALAFEL sandwich is HIT by a TROLLEY-CAR.. Date: Sat, 03 Jul 2010 21:47:40 +0200 In-Reply-To: (MON KEY's message of "Sat, 3 Jul 2010 15:33:58 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 6497 Cc: 6497@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) MON KEY writes: > The "second" foo is bound to the return value of uninterning the > "first" foo e.g. `t'. This is still the first foo. > The evaluation of the indirect-variable for the "second" foo should return `t'. This foo has no value. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 09 14:25:20 2011 Received: (at 6497-done) by debbugs.gnu.org; 9 Jul 2011 18:25:20 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QfcDP-0007vT-RH for submit@debbugs.gnu.org; Sat, 09 Jul 2011 14:25:20 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QfcDO-0007vH-UI for 6497-done@debbugs.gnu.org; Sat, 09 Jul 2011 14:25:19 -0400 Received: from localhost ([127.0.0.1]:55057) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfcDJ-00056v-6i; Sat, 09 Jul 2011 14:25:13 -0400 From: Glenn Morris To: 6497-done@debbugs.gnu.org Subject: Re: bug#6497: documentation `indirect-function', `symbol-function' do not enumerate return value type References: X-Spook: Plame sniper AUTODIN chameleon man e-cash Aldergrove Reno X-Ran: _0Hzi+qRumlR16ML>*A=O+WB3e/hVBI2KMAv22^6ep55YnFh=^!OXy6).oT.[0}t0y+B+z X-Hue: red X-Attribution: GM Date: Sat, 09 Jul 2011 14:25:13 -0400 In-Reply-To: (Andreas Schwab's message of "Sat, 03 Jul 2010 21:47:40 +0200") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 6497-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) I don't see a need to keep open this particular report. From unknown Wed Jun 18 23:08:23 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 07 Aug 2011 11:24:24 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator