Re: (eq #'eq #'eq)

[Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>]

> Date: Thu, 15 Sep 88 07:26 EDT
> From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
> 
> Thanks, JonL.  I was pleased to hear that it is conceivable for a valid CL
> implementation not necessarily to return the same object for 
> (SYMBOL-FUNCTION foo) all the time.  This has ramifications for
> autoloading schemes:  if the function definition for a symbol FOO is
> autoloaded, then the initial contents of the "function cell" of FOO would
> contain a FOO-autoloader, or perhaps some kind of null value; therefore
> just loading up the function cell twice would not result in the same (EQ)
> pointer under such circumstances.  Such freedom is probably necessary in
> order to support function autoloading on (formerly much-maligned until
> recent developments in the business world) "stock hardware".

Sigh.  I don't really want to beat this issue to death, but I don't
think autoloading makes that much difference.  You allow that the
initial contents might be "some kind of null value".  That is very
like what will happen if the function is initially undefined.
(Indeed, some Lisps make autoloading part of the handling for
undefined functions.)  Autoloading is very like defining or redefining
the function.  And that is not much different from doing a SETQ.

But suppose (SYMBOL-FUNCTION F) does contain an autoloader.
Then either SYMBOL-FUNCTION does the autoloading itself
(and returns the real function) or else it returns the autoloader
function.  Presumably it will do the same thing if called again,
and so (eq (symbol-function f) (symbol-function f)) will return
true.

My point is simply this: it would be nice if FUNCTION of a symbol were
simply a way to get the value of the symbol in the function namespace

Would you say Scheme can't support function autoloading?

-- Jeff