From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.bugs Subject: bug#6497: 6497 Date: Sat, 3 Jul 2010 00:27:35 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1278131387 6262 80.91.229.12 (3 Jul 2010 04:29:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 3 Jul 2010 04:29:47 +0000 (UTC) Cc: 6497@debbugs.gnu.org To: Geoff Gole Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jul 03 06:29:45 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 1OUuMJ-0003wq-Rt for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Jul 2010 06:29:44 +0200 Original-Received: from localhost ([127.0.0.1]:44795 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OUuMJ-0002mA-7b for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Jul 2010 00:29:43 -0400 Original-Received: from [140.186.70.92] (port=48543 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OUuMD-0002m5-6J for bug-gnu-emacs@gnu.org; Sat, 03 Jul 2010 00:29:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OUuMC-0001nu-2n for bug-gnu-emacs@gnu.org; Sat, 03 Jul 2010 00:29:37 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45830) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUuMC-0001nq-0X for bug-gnu-emacs@gnu.org; Sat, 03 Jul 2010 00:29:36 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OUuKf-0003GY-Rs; Sat, 03 Jul 2010 00:28:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: MON KEY Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 Jul 2010 04:28:01 +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.127813126212546 (code B ref 6497); Sat, 03 Jul 2010 04:28:01 +0000 Original-Received: (at 6497) by debbugs.gnu.org; 3 Jul 2010 04:27:42 +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 1OUuKL-0003GJ-Mo for submit@debbugs.gnu.org; Sat, 03 Jul 2010 00:27:41 -0400 Original-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 Original-Received: by gwb10 with SMTP id 10so1954100gwb.3 for <6497@debbugs.gnu.org>; Fri, 02 Jul 2010 21:27:35 -0700 (PDT) Original-Received: by 10.100.244.5 with SMTP id r5mr2036570anh.95.1278131255562; Fri, 02 Jul 2010 21:27:35 -0700 (PDT) Original-Received: by 10.151.46.4 with HTTP; Fri, 2 Jul 2010 21:27:35 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: GDQ7W-QJnZpyYBpnbCBcBMSb7v8 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 03 Jul 2010 00:28:01 -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:38207 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. 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\