Hi,
If I use defstruct inside a package, is there an easy way to export
all the resulting functions (make-foo, foo-slot1, ...)? I can do this
manually for a single structure, but it becomes error-prone and
tedious for many.
Thanks,
Tamas
Tamas Papp <······@gmail.com> writes:
> Hi,
>
> If I use defstruct inside a package, is there an easy way to export
> all the resulting functions (make-foo, foo-slot1, ...)? I can do this
> manually for a single structure, but it becomes error-prone and
> tedious for many.
Exported stuff is your interface for other users. Explicit exporting
is one form of documenting the interface, and I prefer it to automagic
exporting techniques.
Zach
Tamas Papp wrote:
> Hi,
>
> If I use defstruct inside a package, is there an easy way to export
> all the resulting functions (make-foo, foo-slot1, ...)? I can do this
> manually for a single structure, but it becomes error-prone and
> tedious for many.
No, but you could probably write your own function that does this for you.
BUT:
A package provides an external interface for other packages to use. It's
most likely a much better idea to control that interface explicitly such
that you know what you have 'promised' to maintain. It may be a drag
while you're experimenting with the design of your code, but as soon as
the interface is stable and published in one way or the other, it's
better to be explicit rather than to be implicit.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Tamas Papp wrote:
>> Hi,
>> If I use defstruct inside a package, is there an easy way to export
>> all the resulting functions (make-foo, foo-slot1, ...)? I can do this
>> manually for a single structure, but it becomes error-prone and
>> tedious for many.
>
> No, but you could probably write your own function that does this for you.
>
> BUT:
>
> A package provides an external interface for other packages to
> use. It's most likely a much better idea to control that interface
> explicitly such that you know what you have 'promised' to maintain. It
> may be a drag while you're experimenting with the design of your code,
> but as soon as the interface is stable and published in one way or the
> other, it's better to be explicit rather than to be implicit.
To reconcile both point of view, instead of writting a Common Lisp
macro to do the job automatically a macroexpansion time, write an
emacs lisp command to do the job automatically at edition time.
Unfortunately, the mismatch between emacs lisp and Common Lisp make it
hard to do well from emacs lisp (you have to handle packages, #+/#-
and other reader macros, readtable case, etc), so it would be better
to do like slime, have an inferior Common Lisp connected and use it to
find the list of symbols defined by the defstruct at point, and then
scan the source for the "current" package (in-package), and the
corresponding defpackage form (could be found in a separate
package.lisp or packages.lisp file...) to be updated.
It would be much simplier to implement in climacs or hemlock...
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Pascal Bourguignon wrote:
> the mismatch between emacs lisp and Common Lisp make it hard to do
> well from emacs lisp (you have to handle packages, #+/#- and other
> reader macros, readtable case, etc)
So it's almost like you'd have to implement a full CL reader in Emacs
Lisp? I bet someone could do that.
Lars Brinkhoff <·········@nocrew.org> writes:
> Pascal Bourguignon wrote:
>> the mismatch between emacs lisp and Common Lisp make it hard to do
>> well from emacs lisp (you have to handle packages, #+/#- and other
>> reader macros, readtable case, etc)
>
> So it's almost like you'd have to implement a full CL reader in Emacs
> Lisp? I bet someone could do that.
Well, there's emacs-cl: http://www.lisp.se/emacs-cl/
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
> Pascal Costanza <····@p-cos.net> writes:
> To reconcile both point of view, instead of writting a Common Lisp
> macro to do the job automatically a macroexpansion time, write an
> emacs lisp command to do the job automatically at edition time.
I agree. I've once hacked my own version of the defclass* (1) macro to
automagically expand slot defintions and export accessors.
However, it makes the code harder to read (there's no standard
convention of naming accessor functions).
Also, it doesn't work well once there are non-standard slot specifiers
introduced by other package.
(e.g. http://common-lisp.net/project/elephant/doc/Persistent-Classes.html#Persistent-Classes)
And now I use a emacs lisp function to do this, which is very simple
and effective.
-- Mac
#1 http://common-lisp.net/project/defclass-star/
On May 28, 9:25 am, Pascal Costanza <····@p-cos.net> wrote:
> Tamas Papp wrote:
> > Hi,
>
> > If I use defstruct inside a package, is there an easy way to export
> > all the resulting functions (make-foo, foo-slot1, ...)? I can do this
> > manually for a single structure, but it becomes error-prone and
> > tedious for many.
>
> No, but you could probably write your own function that does this for you.
>
> ...
> Pascal
>
> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/
When a structure is defined, then "setf" methods to update the fields
are automatically defined. How can I export these, even manually? All
the docs seem to assume the things you are xporting are just symbols
but a setf method is a bit more than that eg (setf line-id).
Tim Josling
Tim Josling <···@melbpc.org.au> writes:
> When a structure is defined, then "setf" methods to update the fields
> are automatically defined. How can I export these, even manually? All
> the docs seem to assume the things you are xporting are just symbols
> but a setf method is a bit more than that eg (setf line-id).
Only symbols can be exported. If a package imports LINE-ID from
your package and SETF from the COMMON-LISP package, then it can
use (SETF LINE-ID). If you want to export the reader functions
but discourage code in other packages from writing to the slots,
Common Lisp has no built-in provision for that, but you can do:
(defstruct (line (:conc-name "%LINE-")) id)
(declaim (inline line-id))
(defun line-id (line) (%line-id line))
(export 'line-id)
With DEFCLASS, it's even easier because you can directly specify
multiple names for reader and accessor functions.
In article <··············@pu100877.student.princeton.edu>,
Tamas Papp <······@gmail.com> wrote:
> Hi,
>
> If I use defstruct inside a package, is there an easy way to export
> all the resulting functions (make-foo, foo-slot1, ...)? I can do this
> manually for a single structure, but it becomes error-prone and
> tedious for many.
Actually, you can't do it manually either.
There is no such thing as "exporting a function" in Common Lisp. You
can only export symbols. These symbols may have function bindings, but
exporting a symbol with a function binding is not the same thing as
exporting a function.
rg