is there a difference between fdefinition and symbol-function? They seem
mostly identical. When use one over the other?
If they are different (which they must be, since
(eq #'fdefinition #'symbol-function)
==> NIL
but does this difference, whatever it is, apply to the mutators (i.e. setf
methods), or just the accessors? (or both?)
dave
From: Christopher R. Barry
Subject: Re: fdefinition vs. symbol-function
Date:
Message-ID: <87g11wu2lv.fsf@2xtreme.net>
David Bakhash <·····@bu.edu> writes:
> is there a difference between fdefinition and symbol-function? They seem
> mostly identical. When use one over the other?
>
> If they are different (which they must be, since
>
> (eq #'fdefinition #'symbol-function)
>
> ==> NIL
Your reasoning as to why they must be different is a little flawed.
For example, NULL and NOT do the _exact_ same thing but it is
implementation-dependant whether their function objects will compare
equal using any equality predicate. I've never seen their function
objects compare equal under any implementation.
Christopher
In article <··············@2xtreme.net>,
Christopher R. Barry <······@2xtreme.net> wrote:
>David Bakhash <·····@bu.edu> writes:
>
>> is there a difference between fdefinition and symbol-function? They seem
>> mostly identical. When use one over the other?
>>
>> If they are different (which they must be, since
>>
>> (eq #'fdefinition #'symbol-function)
>>
>> ==> NIL
>
>Your reasoning as to why they must be different is a little flawed.
>For example, NULL and NOT do the _exact_ same thing but it is
>implementation-dependant whether their function objects will compare
>equal using any equality predicate. I've never seen their function
>objects compare equal under any implementation.
Right. Their definitions might look something like:
(defun null (x)
(eq x nil))
(defun not (x)
(null x))
Actually, it's more likely:
(defun null (x)
(null x))
(defun not (x)
(not x))
If you think this is infinite recursion, think again about compiler
open-coding low-level built-ins. The compiler already knows how to compile
things like (null x) directly into machine code; the above definitions are
just necessary to create function objects for each of these built-ins.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
······@2xtreme.net (Christopher R. Barry) writes:
> For example, NULL and NOT do the _exact_ same thing but it is
> implementation-dependant whether their function objects will compare
> equal using any equality predicate. I've never seen their function
> objects compare equal under any implementation.
Harlequin LW 4.1 under Windows:
CL-USER 21 > (eq (fdefinition 'not) (fdefinition 'null))
T
dave
In article <···············@acs5.bu.edu>, David Bakhash <·····@bu.edu> wrote:
> is there a difference between fdefinition and symbol-function? They seem
> mostly identical. When use one over the other?
SYMBOL-FUNCTION takes a symbol as an argument.
FDEFINITION takes a function name as an argument.
A function name can be a symbol or a list. Example
(fdefinition '(setf foo-bar))
right. of course. I forgot that you can't say (symbol-function '(setf foo)).
This reminds me of something.
after defining a struct with defstruct, it seems that the accessors and
mutators that it creates are all closures. Therefore, if you say:
(defstruct person name age)
and then do
(fdefinition 'person-name)
you'll get some kind of closure subfunction accessor. but if you do:
(fdefinition '(setf person-name))
you get an error. Why? What's different about the mutator in the case of
defstruct?
dave
In article <···············@acs5.bu.edu>, David Bakhash <·····@bu.edu> wrote:
>(defstruct person name age)
>
>and then do
>
>(fdefinition 'person-name)
>
>you'll get some kind of closure subfunction accessor. but if you do:
>
>(fdefinition '(setf person-name))
>
>you get an error. Why? What's different about the mutator in the case of
>defstruct?
It may be defined as a macro-like SETF expander (like what DEFSETF and
DEFINE-SETF-EXPANDER create) rather than a SETF function. The (setf
<symbol>) name only works for the latter.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@bbnplanet.com> writes:
> In article <···············@acs5.bu.edu>,
> David Bakhash <·····@bu.edu> wrote:
> >(defstruct person name age)
> >
> >and then do
> >
> >(fdefinition 'person-name)
> >
> >you'll get some kind of closure subfunction accessor. but if you do:
>
> >(fdefinition '(setf person-name))
> >
> >you get an error. Why? What's different about the mutator in the case of
> >defstruct?
>
> It may be defined as a macro-like SETF expander (like what DEFSETF and
> DEFINE-SETF-EXPANDER create) rather than a SETF function. The (setf
> <symbol>) name only works for the latter.
Barry's explanation is right. But following on this, I feel again compelled
to encourage some meta-problem-solving here. Specifically:
What would make you think otherwise?
Things happen in a language because they are specified to happen.
When they aren't specified, it's curious [and I'm being polite here]
that people just "invent" things that should happen and hope that
their wishing a thing in the absence of having read (or, at least,
cited text about) something saying it will happen that way.
e.g., from the CLHS entry for DEFSTRUCT:
Component reader functions
Reader functions are defined to read the components of the structure. [...]
setf can be used with any of these reader functions to alter the
slot contents.
No hint of (setf foo) functions here. And later it's even more clear, in a
way that might prevent the use of #'(setf foo), actually. I'm not 100% sure
this isn't an error in intent, and if it is an error in intent, I can't say
if it was mine or Steele's or Kathy's. But in any case, it can certainly be
read to give permission for DEFSETF, and might be read to give permission to
do nothing other than DEFSETF:
setf can be used to alter the components of a ship:
(setf (ship-x-position ship2) 100)
This alters the x-position of ship2 to be 100. This works because
defstruct behaves as if it generates an appropriate defsetf for each
access function.
This question you ask, therefore, is a little like the general kind of
"have you stopped beating your wife?" questions that presuppose a false
premise and are hard to answer. If I say:
Whenever I go into a closet, it's always dark. Why is that?
This appears to make a statement either about all closets or about all closets
when you personally are in them, as if they were sensitive to you in a way
they were not to others.
The fact is that closets either do or don't have lights. It is not a
property of all closets that they don't, but any given closet will tend
to be consistent on this. It is a really important evolution in understanding
that I really think is fundamental (and should be taught early in grade school)
that people should understand the difference between "an instance of something
happening" and "how things necessarily happen" and not confuse the two.
If you teach yourself to speak precisely, talking about
implementations when you mean implementations about about languages
when you mean languages and about personal remembrances when you mean
that, I think you will make it easier on yourself and others.
A question like
Whenever I go into my closet, it's always dark. Why is that?
might elicit similar responses, but will not confuse people into thinking
you're asking a question which is the inverse of the question:
Whenever I go into a refrigerator, it's always light. Why is that?
Now THAT is a question that really is about all refrigerators, and properly
phrased comes out right. If you say "my refrigerator", it allows someone
to conveniently tell you it's more general.
I heard on the radio a story about someone recently at some company who
had been editing copy for an advertisement and had seen a 1-877-xxx-xxxx
number, and had thought "there are no toll-free numbers other than
1-800-xxx-xxxx" numbers (which is false) but had not thought "i might not
know the answer to this" and so had "helpfully" "corrected" the text (changing
877 to 800) without stopping to question his more basic assumptions,
causing a lot of calls to a wrong place when the text when into print ...
(For those outside the US, toll-free numbers within the US are now at 1-800,
1-888, and 1-877 because of the overflow from the first range. Other
8xx numbers might or might not now or in the future be toll-free.)
thanks for being subtle, Kent.
I didn't know it was such a stirring question. I apologize for it.
The confusion I had may partially have been b/c I didn't know that things
like:
(defun (setf fname))
and
(defsetf ...)
were handled so differently, though now it's obvious. I am sorry for not
having made that connection before asking. I realized it after reading
Barry's post, though.
dave
David Bakhash <·····@bu.edu> writes:
> The confusion I had may partially have been b/c I didn't know that things
> like:
>
> (defun (setf fname))
>
> and
>
> (defsetf ...)
>
> were handled so differently, though now it's obvious. I am sorry for not
> having made that connection before asking. I realized it after reading
> Barry's post, though.
SETF has a whole huge section in CLHS and CLTL because it's so complicated.
It's really important that people read and understand it if they're going
to be making more than casual use of the language; and by the number of
questions you ask, I have to assume you're among that set.
[ Btw, if you think about why #'(setf whatever) is not "enough",
you will come immediately to that SETQ problem I mentioned in another
thread. SETF of a lexical variable cannot be implemented by
a #'(setf whatever) since any function [other than a lexically bound
one in the right scope] cannot see anything other than its own
lexical contour and cannot "reach" the lexical variable. DEFSETF,
because it is macro-like, has access to the lexical environment and
so can do more things. I'd personally be happy if SETF didn't do the
SETQ service, but I know others who wouldn't like that, so...]
Kent M Pitman <······@world.std.com> wrote:
+---------------
| No hint of (setf foo) functions here. And later it's even more clear,
| in a way that might prevent the use of #'(setf foo), actually.
+---------------
Hmmm... Then does that mean that CMUCL is "broken"?
* (defstruct person name age)
PERSON
* (fdefinition 'person-name)
#<Closure Over Function "DEFUN STRUCTURE-SLOT-ACCESSOR" {9018961}>
* (fdefinition '(setf person-name))
#<Closure Over Function "DEFUN STRUCTURE-SLOT-SETTER" {90189B1}>
* #'(setf person-name)
#<Closure Over Function "DEFUN STRUCTURE-SLOT-SETTER" {90189B1}>
*
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
In article <············@fido.engr.sgi.com>,
Rob Warnock <····@rigden.engr.sgi.com> wrote:
>Kent M Pitman <······@world.std.com> wrote:
>+---------------
>| No hint of (setf foo) functions here. And later it's even more clear,
>| in a way that might prevent the use of #'(setf foo), actually.
>+---------------
>
>Hmmm... Then does that mean that CMUCL is "broken"?
I think Kent was correct that it was an error in verbiage. The sentence he
quoted almost certainly predates the introduction of SETF functions, and it
was an editing error to leave it wored that way. Prior to this, saying
that something behaves as if it generates a DEFSETF was just another way of
saying that SETF works with it. A literal reading of it would also
prohibit DEFSTRUCT from expanding into a DEFINE-SETF-EXPANDER rather than
DEFSETF, which is also an unlikely intent.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@bbnplanet.com> writes:
> In article <············@fido.engr.sgi.com>,
> Rob Warnock <····@rigden.engr.sgi.com> wrote:
> >Kent M Pitman <······@world.std.com> wrote:
> >+---------------
> >| No hint of (setf foo) functions here. And later it's even more clear,
> >| in a way that might prevent the use of #'(setf foo), actually.
> >+---------------
> >
> >Hmmm... Then does that mean that CMUCL is "broken"?
You removed the part of my post in which I said there was room for
implementations to quibble over this. I'm not going to opine on
what implementations are broken and what are not. In the end,
the market decides that. I personally regard it as a design error for
the language to overspecify this, so if the wording were able to
be construed such that this was an error, I think that would be sad.
As Barry suggests here below, it's probably just an editing error and
not a design error that there is even any question.
> I think Kent was correct that it was an error in verbiage. The sentence he
> quoted almost certainly predates the introduction of SETF functions, and it
> was an editing error to leave it wored that way. Prior to this, saying
> that something behaves as if it generates a DEFSETF was just another way of
> saying that SETF works with it. A literal reading of it would also
> prohibit DEFSTRUCT from expanding into a DEFINE-SETF-EXPANDER rather than
> DEFSETF, which is also an unlikely intent.