Re: Sharp with exports in defpackage??


Jonathon McKitrick wrote:
Is there an advantage in using # with exports in defpackage?

I read once that, IIRC, with # the symbols do not end up taking as much
space, or something like that. Would someone mind clarifying?

More precisely, #:name symbols do not get interned by the reader into
any package. :name symbols also can be used reliably, but get interned
by the reader into the keyword package. "NAME'" strings do not get
interned into any package, either, but require one to strike the caps
lock key twice, or remember the upcase keystroke in your editor, and
are a reminder that you are not in the C/UNIX world. Whether that
reminder is painful or not is a complex psychological question.

Other symbols could be used, but I'm pretty sure there is a serious
failure mode that I can't remember, because the reader will intern that
symbol into the current package. You are creating your own package
precisely to keep from cluttering up somebody else's namespace, so at
the very least the reader is being rude on your behalf. The keyword
package is a safe "dump"; any symbols you put in there will not cause
any conflict, because keywords are restricted in their possible
function.

The interning of the keyword symbol (or a symbol in any other package)
means there is a permanent reference from the keyword (or the other)
package pointing at the symbol you used to name the exported symbol,
which can never be discarded. You might get lucky, and the keyword
would have been used by someone else anyway, but generally, this
keyword is an extra "twin" of the symbol you meant to generate,
consuming memory for no purpose. This is the space consumption the
other techniques try to avoid. The #:name symbol (or "NAME" string)
will become garbage as soon as the defpackage form is done extracting
its symbol-name. Eventually, the garbage collector will free it.

I also find the keyword technique slightly disturbing because it causes
APROPOS to find "false positives" littered in the keyword package. This
is related to the problem of generating extra symbols in the
COMMON-LISP-USER package when one forgets to use the proper package
qualification at the REPL.

.

Relevant Pages

  • Re: Sharpsign-colon ... why here?
    ... The root of the issue is the reader interning symbols in uppercase by ... the COMMON-LISP package). ... with the ANSI default and those who want to use a case preserving Lisp ... case preserving reader will intern the symbol in the provided case ...
    (comp.lang.lisp)
  • Re: atoms in a list interned when called by another package. why?
    ... I call this when I'm in another package I will get this: ... The READer does intern symbols. ... KEYWORD is an exception in that the package name is optional in the ... :ANY-SYMBOL ...
    (comp.lang.lisp)
  • Re: access closure variable
    ... (lambda (command &optional args) ... Keywords are not really package independent. ... :FOO ... The reader will read:foo as a symbol in the keyword package. ...
    (comp.lang.lisp)
  • Re: help me pick a name for my project!
    ... because we can provide an interface to ... package, for those of our colleagues who don't ... create or replace package keyword ... def add: ...
    (comp.databases.oracle.misc)
  • help me pick a name for my project!
    ... the database that looks like a standard python ... package, for those of our colleagues who don't ... create or replace package keyword ... def add: ...
    (comp.databases.oracle.misc)