Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

DEFSETF and packages

64 views
Skip to first unread message

Carlos

unread,
Aug 13, 2012, 10:01:55 AM8/13/12
to
Hello,

I had to add some missing functionality, so I did

(in-package :my-utils)

(defun set-file-write-date (file date) ... )

(defsetf file-write-date set-file-write-date)

and... that was it! I didn't have to export anything, not even
SET-FILE-WRITE-DATE. I can use (setf file-write-date) from
anywhere.

That's... odd, isn't it?

--

Zach Beane

unread,
Aug 13, 2012, 10:09:46 AM8/13/12
to
The behavior is undefined per http://l1sp.org/cl/11.1.2.1.2 clause 13,
sorry. An implementation that locks the CL package (like SBCL and
others) will reject your code.

Aside from that, the reference from (setf file-write-date) to your
internal symbol is not explicit in calls to setf, so you don't have to
do anything special to use it.

Zach

Carlos

unread,
Aug 13, 2012, 11:22:06 AM8/13/12
to
On Mon, 13 Aug 2012 10:09:46 -0400
Zach Beane <xa...@xach.com> wrote:

> Carlos <an...@quovadis.com.ar> writes:
>
> > Hello,
> >
> > I had to add some missing functionality, so I did
> >
> > (in-package :my-utils)
> >
> > (defun set-file-write-date (file date) ... )
> >
> > (defsetf file-write-date set-file-write-date)
> >
> > and... that was it! I didn't have to export anything, not even
> > SET-FILE-WRITE-DATE. I can use (setf file-write-date) from
> > anywhere.
> >
> > That's... odd, isn't it?
>
> The behavior is undefined per http://l1sp.org/cl/11.1.2.1.2 clause 13,
> sorry. An implementation that locks the CL package (like SBCL and
> others) will reject your code.

Oh, I see. Anyway, this happening when one package isn't CL doesn't
seem *so* odd, but nevertheless is a little baffling.

> Aside from that, the reference from (setf file-write-date) to your
> internal symbol is not explicit in calls to setf, so you don't have to
> do anything special to use it.

It seems strange for a package to be able to add a setf function for
another's package symbol and for that function to "piggyback" the
exported status of the original function's symbol. Intuitively, I would
expect to be required to do something like "(:export '(setf xxxx))".

But I understand why it happens at the technical level. Thanks.

--

Zach Beane

unread,
Aug 13, 2012, 11:24:01 AM8/13/12
to
Carlos <an...@quovadis.com.ar> writes:

>> Aside from that, the reference from (setf file-write-date) to your
>> internal symbol is not explicit in calls to setf, so you don't have to
>> do anything special to use it.
>
> It seems strange for a package to be able to add a setf function for
> another's package symbol and for that function to "piggyback" the
> exported status of the original function's symbol. Intuitively, I would
> expect to be required to do something like "(:export '(setf xxxx))".

It helps to understand that packages are for managing *only* symbols,
and not any of the concepts or features attached to the symbols. You
aren't exporting *functions*, you're only exporting *names*. And the
packages don't know what the names they manage actually name.

Zach

Carlos

unread,
Aug 13, 2012, 11:40:49 AM8/13/12
to
Yes, I understand. But it somewhat clashes with the concept that a
function can be named "(setf xxxx)". We can really only export atomic
names... :-/

--

0 new messages