From: Sam Steingold
Subject: do `accessors' have to be functions?
Date:
Message-ID: <u8zb9rcn4.fsf@xchange.com>
Many CL functions are named "accessors" (such as CAR, LDB &c).
While `accessor' (as defined by the glossary) is an `operator' (which,
in turn, may be a function, macro or a special operator), one would
surely expect CAR to be a function, not a macro.
What about (SETF CAR)?
Specifically, is it true that
#'(SETF foo)
is compliant code for all `foo' which ANSI CL calls accessors and
for which is specifies a SETF behavior?
LispWorks, CMUCL and CLISP all barf on, say, #'(SETF LDB).
Thanks.
--
Sam Steingold (http://www.podval.org/~sds)
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
Let us remember that ours is a nation of lawyers and order.
In article <·············@xchange.com>, "Sam Steingold" <···@gnu.org>
wrote:
> Many CL functions are named "accessors" (such as CAR, LDB &c). While
> `accessor' (as defined by the glossary) is an `operator' (which, in
> turn, may be a function, macro or a special operator), one would surely
> expect CAR to be a function, not a macro. What about (SETF CAR)?
> Specifically, is it true that
> #'(SETF foo)
> is compliant code for all `foo' which ANSI CL calls accessors and for
> which is specifies a SETF behavior?
Absolutely not!
LispWorks, CMUCL and CLISP all barf
> on, say, #'(SETF LDB). Thanks.
>
And why do you think that is? defsetf and define-setf-expander exist for
a reason...
Tim
"Tim Moore" <·····@bricoworks.com> wrote in message news:<············@216.39.145.192>...
> In article <·············@xchange.com>, "Sam Steingold" <···@gnu.org>
> wrote:
>
> > Many CL functions are named "accessors" (such as CAR, LDB &c). While
> > `accessor' (as defined by the glossary) is an `operator' (which, in
> > turn, may be a function, macro or a special operator), one would surely
> > expect CAR to be a function, not a macro. What about (SETF CAR)?
> > Specifically, is it true that
> > #'(SETF foo)
> > is compliant code for all `foo' which ANSI CL calls accessors and for
> > which is specifies a SETF behavior?
>
> Absolutely not!
> LispWorks, CMUCL and CLISP all barf
> > on, say, #'(SETF LDB). Thanks.
>
> And why do you think that is? defsetf and define-setf-expander exist for
> a reason...
I started this controversy on clisp-list by arguing that
#'(SETF SYMBOL-FUNCTION) should exist.
My reasoning:
* The HyperSpec dictionary entry for SYMBOL-FUNCTION says it's an "accessor".
* The HyperSpec section "1.4.4.14 The ``Name'' Section of a Dictionary Entry"
says that in the context of the ``Name'' section of a dictionary entry,
"accessor" is to be interpreted as "accessor function". To quote the
relevant part:
In somewhat smaller italic print at right is an indication of what
kind of dictionary entry this is. Possible values are:
Accessor
This is an accessor function.
Thus, SYMBOL-FUNCTION should be a function. It doesn't strictly follow that
the SETF operation for SYMBOL-FUNCTION should also be a function, but I
thought it was natural for it to be an accessor function just as
SYMBOL-FUNCTION is, since it's also an accessor defined on the same
dictionary page.
Most of the FOOs that the dictionary calls "accessors" seem to
allow an obvious implementation of #'(SETF FOO), and I thought all
of them did, but I didn't notice LDB. I certainly agree with Sam
Steingold that SETF of LDB resists implementation as a function, so
maybe my interpretation is wrong.
In article <············@216.39.145.192>, Tim Moore wrote:
>In article <·············@xchange.com>, "Sam Steingold" <···@gnu.org>
>wrote:
>
>
>> Many CL functions are named "accessors" (such as CAR, LDB &c). While
>> `accessor' (as defined by the glossary) is an `operator' (which, in
>> turn, may be a function, macro or a special operator), one would surely
>> expect CAR to be a function, not a macro. What about (SETF CAR)?
>> Specifically, is it true that
>> #'(SETF foo)
>> is compliant code for all `foo' which ANSI CL calls accessors and for
>> which is specifies a SETF behavior?
>
>Absolutely not!
>LispWorks, CMUCL and CLISP all barf
^^^^^ ^^^^
Sam kind of knows about that one. :) :)
Sam Steingold <···@gnu.org> writes:
> Many CL functions are named "accessors" (such as CAR, LDB &c).
> While `accessor' (as defined by the glossary) is an `operator' (which,
> in turn, may be a function, macro or a special operator), one would
> surely expect CAR to be a function, not a macro.
>
> What about (SETF CAR)?
>
> Specifically, is it true that
> #'(SETF foo)
> is compliant code for all `foo' which ANSI CL calls accessors and
> for which is specifies a SETF behavior?
I don't think so. I had thought this might be specified somewhere but
didn't see it when I just went to look. I'll maybe try again later if
no one else finds anything in the interim.
> LispWorks, CMUCL and CLISP all barf on, say, #'(SETF LDB).
I don't think you can implement SETF of LDB correctly without using a macro.
Same with SETF of GETF or SETF of SYMBOL-PLIST.
Do you have a proposed implementation for these? The only operations that
are even possible to implement as functions are ones that, by their nature,
get an object as arg which is implicitly the "locative" to the cell into
which the value must be stored.
From: Sam Steingold
Subject: Re: do `accessors' have to be functions?
Date:
Message-ID: <uy9j9ps8m.fsf@xchange.com>
> * In message <···············@shell01.TheWorld.com>
> * On the subject of "Re: do `accessors' have to be functions?"
> * Sent on Tue, 8 Jan 2002 00:31:13 GMT
> * Honorable Kent M Pitman <······@world.std.com> writes:
>
> Sam Steingold <···@gnu.org> writes:
>
> > Many CL functions are named "accessors" (such as CAR, LDB &c).
> > While `accessor' (as defined by the glossary) is an `operator' (which,
> > in turn, may be a function, macro or a special operator), one would
> > surely expect CAR to be a function, not a macro.
> >
> > What about (SETF CAR)?
> >
> > Specifically, is it true that
> > #'(SETF foo)
> > is compliant code for all `foo' which ANSI CL calls accessors and
> > for which is specifies a SETF behavior?
>
> I don't think so. I had thought this might be specified somewhere but
> didn't see it when I just went to look. I'll maybe try again later if
> no one else finds anything in the interim.
William Harold Newman <··············@airmail.net> wrote on <clisp-list>
that CLISP is non-compliant in barfing on #'(setf symbol-function), and
I said that it was a macro in CLISP, and he said that it must be a
function because:
| Eventually, I found support for the behavior I expected, in "1.4.4.14
| The ``Name'' Section of a Dictionary Entry". It says
| This section introduces the dictionary entry. It is not explicitly
| labeled. It appears preceded and followed by a horizontal bar.
| In large print at left, the defined name appears; if more than one
| defined name is to be described by the entry, all such names are
| shown separated by commas.
| In somewhat smaller italic print at right is an indication of what
| kind of dictionary entry this is. Possible values are:
| Accessor
| This is an accessor function.
| [etc.]
| So: I think when you see "accessor" at the head of an entry in the
| symbols dictionary, it is to be interpreted as "accessor function".
| (And yes, this *does* seem like a remarkably indirect and confusing
| way to specify the function-not-macro-ness of things like CAR.)
this would imply that (SETF LDB) _must_ be a function too.
> > LispWorks, CMUCL and CLISP all barf on, say, #'(SETF LDB).
>
> I don't think you can implement SETF of LDB correctly without using a macro.
> Same with SETF of GETF or SETF of SYMBOL-PLIST.
yep.
> Do you have a proposed implementation for these?
not at all.
I am just trying to figure out whether I must provide function
definitions for all (SETF ...) macros in CLISP.
--
Sam Steingold (http://www.podval.org/~sds)
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
Who is General Failure and why is he reading my hard disk?
* Sam Steingold <···@gnu.org>
| I am just trying to figure out whether I must provide function
| definitions for all (SETF ...) macros in CLISP.
The proper interface to setf is through the macro expansion. If that
macro expansion returns a simple function, I think it is appropriate to
let that function be named (setf ...) rather than some weird internal
name. If that macro expansion does not return a simple function, well,
the question is moot.
///
--
From: Sam Steingold
Subject: (fboundp '(setf ldb)) [was Re: do `accessors' have to be functions?]
Date:
Message-ID: <upu4kq05k.fsf_-_@xchange.com>
> * In message <···············@shell01.TheWorld.com>
> * On the subject of "Re: do `accessors' have to be functions?"
> * Sent on Tue, 8 Jan 2002 00:31:13 GMT
> * Honorable Kent M Pitman <······@world.std.com> writes:
>
> Sam Steingold <···@gnu.org> writes:
>
> > Specifically, is it true that
> > #'(SETF foo)
> > is compliant code for all `foo' which ANSI CL calls accessors and
> > for which is specifies a SETF behavior?
>
> I don't think so.
>
> > LispWorks, CMUCL and CLISP all barf on, say, #'(SETF LDB).
>
> I don't think you can implement SETF of LDB correctly without using a macro.
Thanks a lot for your clarifications.
Now, just to nail the thing down:
if (SETF FOO) is a macro (e.g., FOO is LDB),
do I understand correctly that
(fboundp '(setf foo)) ==> NIL
(fdefinition '(setf foo)) ==> error
(fmakunbound '(setf foo)) ==> (setf foo),
but (setf (foo ...) ...) still works
as appears to follow from the glossary entry:
bound ['ef,band] adj. (of a function name) bound in the function
namespace. (The names of macros and special operators are fbound, but
the nature and type of the object which is their value is
implementation-dependent. Further, defining a setf expander F does not
cause the setf function (setf F) to become defined; as such, if there is
a such a definition of a setf expander F, the function (setf F) can be
fbound if and only if, by design or coincidence, a function binding for
(setf F) has been independently established.) See the functions fboundp
and symbol-function.
[Personally, I find this behavior not too intuitive: for symbols,
FBOUNDP, FDEFINITION and FMAKUNBOUND behave the same for macros and
functions, while for (SETF ...) names they differ for macros and
functions]
thanks.
--
Sam Steingold (http://www.podval.org/~sds)
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
Why use Windows, when there are Doors?
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
>Sam Steingold <···@gnu.org> writes:
>
>> Many CL functions are named "accessors" (such as CAR, LDB &c).
>> While `accessor' (as defined by the glossary) is an `operator' (which,
>> in turn, may be a function, macro or a special operator), one would
>> surely expect CAR to be a function, not a macro.
>>
>> What about (SETF CAR)?
>>
>> Specifically, is it true that
>> #'(SETF foo)
>> is compliant code for all `foo' which ANSI CL calls accessors and
>> for which is specifies a SETF behavior?
>
>I don't think so. I had thought this might be specified somewhere but
>didn't see it when I just went to look. I'll maybe try again later if
>no one else finds anything in the interim.
I think the only SETF expansions that are required to be #'(SETF foo) are
the ones where #'foo is a CLOS accessor generic function. #'(SETF foo) was
added to the language specifically to support CLOS, but the rest of the
SETF mechanism already existed. We didn't go back and require changes in
how the other standard SETF methods must be implemented; it's an
implementation detail whether they use SETF expanders, SETF functions, or
perhaps hard-coded knowledge in the SETF macro itself.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, 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.