From: MON KEY <monkey@sandpframing.com>
To: Geoff Gole <geoffgole@gmail.com>
Cc: 6497@debbugs.gnu.org
Subject: bug#6497: 6497
Date: Sat, 3 Jul 2010 00:27:35 -0400 [thread overview]
Message-ID: <AANLkTiktK7rDenqUZYV6z5JGLiJGLFPEzEMWOIxsA7DV@mail.gmail.com> (raw)
In-Reply-To: <AANLkTins7-pIYHXOPDSZyRnQgy_BZ3r4HBznQms2e2HN@mail.gmail.com>
>> 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))
;=> #<subr indirect-function>
following should evaluate to `#<subr indirect-function>' 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\
next prev parent reply other threads:[~2010-07-03 4:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-22 23:42 bug#6497: documentation `indirect-function', `symbol-function' do not enumerate return value type MON KEY
2010-07-01 9:20 ` bug#6497: 6497 Geoff Gole
2010-07-02 0:13 ` MON KEY
2010-07-02 1:39 ` Geoff Gole
2010-07-03 4:27 ` MON KEY [this message]
2010-07-03 6:31 ` Geoff Gole
2010-07-03 19:35 ` MON KEY
2010-07-03 7:00 ` Andreas Schwab
2010-07-03 19:33 ` MON KEY
2010-07-03 19:47 ` Andreas Schwab
2011-07-09 18:25 ` bug#6497: documentation `indirect-function', `symbol-function' do not enumerate return value type Glenn Morris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTiktK7rDenqUZYV6z5JGLiJGLFPEzEMWOIxsA7DV@mail.gmail.com \
--to=monkey@sandpframing.com \
--cc=6497@debbugs.gnu.org \
--cc=geoffgole@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.