Re: Multiple copies of functions

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

> Consider DEFSTRUCT.  DEFSTRUCT creates functions like make-foo, foo-slot,
> foo-p, etc., etc.

Summary: they are no different from DEFUN'd functions except that they
tend to get compiled in-line.

> These are mandated to be functions, although they used to be created as
> macros in earlier Lisps.  To retain efficiency, a compiler will probably
> want to compile them as inline structure-accessors and the like, as if
> they really were macros.  The only case where you really need the body
> of a function sitting around for them is in references like #'foo-slot.

Or if I proclaim them NOTINLINE.  In fact, as far as I know, nothing in
CLtL prevents the in-line compilation of *any* function provided it is
not declared NOTINLINE.  

> In that case, it probably makes sense for the compiler to generate code
> for foo-slot iff there is a #'foo-slot reference.  Since these functions
> are built by the expansion of DEFSTRUCT, rather than living in some
> permanent place, and they may be created only when needed (even if not,
> they still have to get created),

Um, functions are normally built by the expansion of the DEFUN macro,
so I don't see that DEFSTRUCT is so different from the normal case.
DEFUN'd functions could also not be created unless needed.  Of course,
given that the DEFUN (or the DEFSTRUCT) might be in one file and the
call to it in another, the function probably will be attached to the
name in any case.  And once it is, Lisp may as well return THAT
FUNCTION instead of creating a new one.

> it is possible for the compilation of
> wholly separate pieces of code to need the "same" function (and you 
> would agree that they are the "same", would you not?).  In such a case,
> the function body referenced by #'foo-slot in one program may be at a
> different virtual address from the function body referenced by another.

The address may be different for different in-line compilations, but
I don't see any point in having FUNCTION and hence SYMBOL-FUNCTION
build functions from different blocks of compiled code depending on
where they're called.  And how about when I do something like

   (funcall some-function 'f)

SOME-FUNCTION might turn out to be SYMBOL-FUNCTION.  I suppose
SYMBOL-FUNCTION might (and still be valid Common Lisp) compile the
source code and return a new function each time, or something of that
sort, but my point is simply that there's no good reason to do so.
So, I don't see why Common Lisp should allow this freedom.  (Well,
one reason has been suggested -- from InterLisp -- but I don't
think your new reason is sufficiently convincing.)

> Maybe this wouldn't be sufficiently "same" for a number of reasons.
> But I think that one could, if one put one's mind to it, come up with
> some situation where there are two copies of the "same" function that
> reside at different memory locations (invalidating EQ as a comparison),
> yet for all intents and purposes are the "same" code.  

There would be two copies of the same if they're compiled in-line.
Otherwise, I don't see why one would want to do this.

I don't want EQ to tell me if two functions are the "same function";
I want it to tell me whether two objects that are both functions are
the same identical object; and EQ does do this.  The remaining
question is whether (FUNCTION <symbol>) should create a new function
or simply return one.  Neither decision for FUNCTION invalidates EQ
as a comparison for identity of function objects.

Again, I suspect we are really interested in different questions.

> I'd be happy to drop this topic.  I think I've learned a lot about the
> possible approaches to the problem, and I don't want to descend into
> an operating-system-dependent mode.  

Well, nothing that is operating-system dependent has yet come up,
so I suppose we can still stop in time.

Cheers,
Jeff