And if you ever wondered why CLOS makes you spell out the names of readers and accessors, this is why. CLOS does not want to make any assumptions about how you want to make decisions about what packages things are in.
It's the "right thing" rather than the "worse is better" way, with all the usual issues. In our own code, we have a "define-class" macro that defines all accessors automatically, interning them in the package that makes sense for us. It's kind of a middle path between defstruct and defclass. I don't love it but I don't hate it...
-- Dan
On Sun, Jul 3, 2011 at 7:11 AM, Pascal J. Bourguignon <pjb@informatimago.com
wrote:
Kazimir Majorinc kazimir@chem.pmf.hr writes:
I need comprehensive review of use of generated symbols (make-symbol, copy-symbol, gensym... ) in CL. The books I have (both Grahams, Siebel, barely mention these operators, except for use of gensym in macros.
What are other typical or interesting uses of these?
The most typical use, is a defstruct like macro, which derivates "public" names from a base name.
(DEFSTRUCT COLOR RED GREEN BLUE)
generates function definitions for:
MAKE-COLOR COLOR-P COPY-COLOR COLOR-RED COLOR-GREEN COLOR-BLUE
Ask yourself, what should:
(DEFSTRUCT other-package:|color| |Red| other-package:|GREEN| |blue|)
generate?
(And the effect *print-case* should or should not have on that...)
-- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.
pro mailing list pro@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro