GNU bug report logs - #6497
documentation `indirect-function', `symbol-function' do not enumerate return value type

Previous Next

Full log

Message #14 received at 6497 <at> debbugs.gnu.org (full text, mbox):

From: Geoff Gole <geoffgole <at> gmail.com>
To: MON KEY <monkey <at> sandpframing.com>
Cc: 6497 <at> debbugs.gnu.org
Subject: Re: 6497
Date: Fri, 2 Jul 2010 09:39:38 +0800

> 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)) => 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)
> => (void-variable indirect-function)   ;; <-- void-variable

> (indirect-function not-a-real-function)
> => (void-variable not-a-real-function) ;; <-- void-variable

> (indirect-function symbol-function)
> => (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
>  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'.

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:
>
>  - a lambda form
>  - a vector
>  - a list
>  - a cons
>  - 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.