From: Kent M Pitman
Subject: Re: function vs. symbol-function
Date: 
Message-ID: <sfwk911yc8k.fsf@world.std.com>
Paul Rudin <·····@shodan.demon.co.uk> writes:

> (defun foo () 'bar)
> 
> #'foo => foo
 
This looks like a bug to me.  Per CLHS, the special operator FUNCTION
returns "a function object".  Definition 2 of "object" says:
"(immediately following the name of a type) an object which is of that type,
used to emphasize that the object is not just a name for an object but really
an element of that type in cases where objects of that type (such as FUNCTION
or CLASS) are commonly referred to by name."  I think #'foo should in the
simple case you use return the same as (symbol-function 'foo).

> wheras 
> 
> (symbol-function 'foo) => #<function 0 #x148D5C8>
> 
> 
> is this an implementation specific issue - i.e. if I were using an
> interpreter rather than a compiler I'd get the same thing, or is there
> still an essential difference between the two things here? 

As a rule, the semantics aren't dependent on the interpreter/compiler
distinction although in areas like this you can usually detect some
small difference like that it might print as #<INTERPRETED-FUNCTION ...>
in some cases and #<COMPILED-FUNCTION ...> in others, but either would be
"an object of type function".  It is neither supposed to give you a function
name nor a lambda expression.

> Certainly I get:
> 
> (funcall #'foo) => bar
> 
> and
> 
> (funcall (symbol-function 'foo)) => bar

This is because you can funcall a symbol.  (But that doesn't mean #'foo
should be returning one.)

By the way, although everything Barry said is true, I would explain it 
differently:

FUNCTION is intended for use in accessing program environments from programs
and works through the abstraction of "variables in a namespace".

SYMBOL-FUNCTION is a data structure accessor which is conceptually (though
not necessarily literally) a slot accessor.  (Whether a function actually has
a "function cell" is an implementation detail, and we fought over this heavily
in x3j13.  I have always claimed it doesn't matter if you define it to have
one since no one has an operator to tell whether you cheated and only 
demand-allocated it where you need it.  Some people were paranoid and afraid
that if we called it a slot, someone would think you were forced to allocate
storage that no one was ever going to see or know about.  As a rule, I think
ALL programs, no matter how documented, are allowed to cheat and not allocate
storage that no one is ever going to see or know about--indeed, virtual memory
systems may do this for you invisibly whether you ask for it or not by not
paging in pages until they are touched by a program.)

But the place where Barry's description differs from mine, and it's a subtle
point he might not even disagree with really--is just the philosophical issue
of whether "the global function cell is defined to be what SYMBOL-FUNCTION
gets" or whether "the global function cell happens to be defined to be what
SYMBOL-FUNCTION accesses".  You see, if you look at only the current
specification, it makes no difference.  But I personally see Lisp as a
continuum of dialects from the past to the future, and I consider it only an
incidental matter that SYMBOL-FUNCTION happens to get the global value cell;
I could imagine a Lisp in which (funcall 'foo ...) meant 
(funcall (symbol-function 'foo) ...) but did not mean 
(funcall #'foo ...); that is, where the data structure for symbols 
was decoupled from the data structures used by the system itself.  Indeed,
Scheme is sort of like this (although it's hard to see because of the single
namespace and the absence of either SYMBOL-VALUE or SYMBOL-FUNCTION), but
conceptually in scheme you'd expect (symbol-value 'foo) and foo to be
different--except that the scheme people went a step further and removed
(symbol-value 'foo) because once you take away the correspondence between a
symbol qua variable and a symbol qua data, they figured it would be better just
not to have symbol-value at all (and for their purposes, they were probably
right).  Also, if CL had "global lexicals", then those values might or might
not share the symbol's value cell, depending on the implementation.  

So I claim it's better to think of symbol-function as an introspective 
capability to be used in bootstrapping your system (when you're treating
the environment as "data" to be explored) , but to think of function as 
something for programs to use routinely in practice.  (And, once in a while,
you use introspective capabilities at runtime when doing embedded languages
or the like, but it's rarer.  Usually you know the variable you want and you
just name it.)

I fear slightly that I've raised as many questions as I might have answered
here, but feel free to ask if I've left something unclear.

Incidentally, this is a good place to alert people to the literature on 
"reflective" or "introspective" lisps.  Understanding what a reflective 
language is and how reflection manifests itself in programs would help a bit
in seeing the "data" thing here a little better.  (Briefly, in a reflective
Lisp, you assume the program you're running is data for some other program
which is the virtual machine you're running on, and so you assume that it 
has its own parallel set of data structures for keeping track of your program
which you might sometimes peek at.  And that that program has a program
running it which can be peeked at.  And so on up an infinite tower...  There's
a good Alice In Wonderland piece about this, but I don't have it handy so I'll
just stop here.  If memory serves me, Brian C. Smith in his PhD thesis
started this interesting realm of work; a Lisp dialect called 3LISP he
described was reflective in the way I'm describing and even today it always
serves as a model in my mind for thinking about reflection... and for thinking
about thinking about reflection.  and so on.  heh.)

From: Tim Bradshaw
Subject: Re: function vs. symbol-function
Date: 
Message-ID: <ey37lx052bw.fsf@todday.aiai.ed.ac.uk>
* Kent Pitman wrote:
> I could imagine a Lisp in which (funcall 'foo ...) meant 
> (funcall (symbol-function 'foo) ...) but did not mean 
> (funcall #'foo ...); 

Common Lisp is such a Lisp, isn't it?

	(define foo () 2)
	(labels ((foo () 1))
          ...)

Actually I'm slightly confused by your article

--tim
From: Barry Margolin
Subject: Re: function vs. symbol-function
Date: 
Message-ID: <2cF22.85$ri1.1389292@burlma1-snr1.gtei.net>
In article <···············@todday.aiai.ed.ac.uk>,
Tim Bradshaw  <···@aiai.ed.ac.uk> wrote:
>Actually I'm slightly confused by [Kent's] article

Only slightly?

One of the differences between me and Kent is that I try to make my answers
appropriate for the apparently experience level of the person who asked the
question.  Someone who couldn't figure out the difference between FUNCTION
and SYMBOL-FUNCTION from the descriptions in the CLHS or CLTL probably
wouldn't be able to fathom Kent's long missive.  I'll often leave out
obscure details to avoid confusing the intended receiver.

-- 
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.
From: Kent M Pitman
Subject: Re: function vs. symbol-function
Date: 
Message-ID: <sfwr9v84sk2.fsf@world.std.com>
Barry Margolin <······@bbnplanet.com> writes:

> In article <···············@todday.aiai.ed.ac.uk>,
> Tim Bradshaw  <···@aiai.ed.ac.uk> wrote:
> >Actually I'm slightly confused by [Kent's] article
> 
> Only slightly?
> 
> One of the differences between me and Kent is that I try to make my answers
> appropriate for the apparently experience level of the person who asked the
> question.  Someone who couldn't figure out the difference between FUNCTION
> and SYMBOL-FUNCTION from the descriptions in the CLHS or CLTL probably
> wouldn't be able to fathom Kent's long missive.  I'll often leave out
> obscure details to avoid confusing the intended receiver.

Well, in fairness, I figured your answer already covered the novice
question and answer part.  And I didn't dispute it.  But I often
follow simple info with more complex info, and I assume the human 
reader will stop when s/he gets too deep and put the rest aside for
the other day.  This newsgroup would be dreadfully dull if all we 
talked about was stuff intelligible to novices.  And also, I think
novices have some of the best insight into the really hard questions.
Someone said to me recently in conversation--wish I could remember
who--something about experts needing to be "mined" for their knowledge
and novices for their intuitions.  As novices become experts, their
intuitions are tainted and they lose that valuable resource to cynical
pragmatism.
From: Kent M Pitman
Subject: Re: function vs. symbol-function
Date: 
Message-ID: <sfwsofo4sv9.fsf@world.std.com>
Tim Bradshaw <···@aiai.ed.ac.uk> writes:

> * Kent Pitman wrote:
> > I could imagine a Lisp in which (funcall 'foo ...) meant 
> > (funcall (symbol-function 'foo) ...) but did not mean 
> > (funcall #'foo ...); 
> 
> Common Lisp is such a Lisp, isn't it?
> 
> 	(define foo () 2)
> 	(labels ((foo () 1))
>           ...)

Sorry, when I said "meant" I didn't mean to suggest the two operators
were semantically equivalent.  I meant those two specific forms evaluated
as toplevel forms (i.e., no local lexical environment) meant the same thing.
I was speaking very specifically and not flagging it--no wonder you were
confused.
 
> Actually I'm slightly confused by your article

If you want to cite some specific point of confusion, I could try to 
clarify that, too.  I dare not address the topic generally or I'll just
dig myself in deeper. :-)