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?
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.
··············@hotmail.com <············@gmail.com> wrote:
+---------------
| Jonathon McKitrick wrote:
| > Is there an advantage in using # with exports in defpackage? ...
|
| 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...
+---------------
Another reason to use symbols [whether uninterned or keyword]
instead of "NAME" strings is to avoid problems when the user
is running with a non-standard READTABLE-CASE mode. When symbols
such as #:name are typed in in lowercase, they'll "do the right
thing" regardless of whether (READTABLE-CASE *READTABLE) is the
CLHS default :UPCASE or the increasingly-popular-when-doing-FFI
:INVERT mode. Whereas "NAME" breaks in the latter case...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Christophe Rhodes
Subject: Re: Sharp with exports in defpackage??
Date:
Message-ID: <sqek1ng5dy.fsf@cam.ac.uk>
····@rpw3.org (Rob Warnock) writes:
> Another reason to use symbols [whether uninterned or keyword]
> instead of "NAME" strings is to avoid problems when the user
> is running with a non-standard READTABLE-CASE mode. When symbols
> such as #:name are typed in in lowercase, they'll "do the right
> thing" regardless of whether (READTABLE-CASE *READTABLE) is the
> CLHS default :UPCASE or the increasingly-popular-when-doing-FFI
> :INVERT mode. Whereas "NAME" breaks in the latter case...
No it doesn't.
Christophe
Christophe Rhodes <·····@cam.ac.uk> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) writes:
| > Another reason to use symbols [whether uninterned or keyword]
| > instead of "NAME" strings is to avoid problems when the user
| > is running with a non-standard READTABLE-CASE mode. When symbols
| > such as #:name are typed in in lowercase, they'll "do the right
| > thing" regardless of whether (READTABLE-CASE *READTABLE) is the
| > CLHS default :UPCASE or the increasingly-popular-when-doing-FFI
| > :INVERT mode. Whereas "NAME" breaks in the latter case...
|
| No it doesn't.
+---------------
Ouch! You're right. I didn't look carefully enough at *when* casing
got done in this example [in the reader, of course]. And DEFPACKAGE
takes string-designators for all its input symbol arguments anyway,
so they're already in "the right case".
Hmmm... I recall very vaguely from some of the discussions around
here in the past about case-sensitivity that there was a reason for
preferring to use uninterned or keyword symbols over strings, so as
to be more-or-less immune to the READTABLE-CASE, but at the moment
I can't seem to recall the specific situation where this arose.
Mea culpa. "Never mind..."
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Christophe Rhodes
Subject: Re: Sharp with exports in defpackage??
Date:
Message-ID: <sqaccbg28v.fsf@cam.ac.uk>
····@rpw3.org (Rob Warnock) writes:
> Hmmm... I recall very vaguely from some of the discussions around
> here in the past about case-sensitivity that there was a reason for
> preferring to use uninterned or keyword symbols over strings, so as
> to be more-or-less immune to the READTABLE-CASE, but at the moment
> I can't seem to recall the specific situation where this arose.
Probably for those who have to support Allegro CL's non-standard
so-called "modern" mode. (People might be interested in looking at
how CLISP supports case-sensitive development in a manner which is
backward-compatible and standard-compliant by default.)
Christophe