bug#6497: 6497

[MON KEY]

>> 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\