when to use #:
in [Lisp]
|
From: Pascal Costanza on 7 Apr 2010 05:42 On 06/04/2010 16:51, Captain Obvious wrote: > TKP> I am not completely clear on the applications of the #: read macro for > TKP> uninterned symbols. > > If you need symbol only for its name, then interning it into some > package is sub-optimal, both from memory footprint perspective and from > "namespace pollution" perspective -- those symbols will show up in > output of apropos and completions in IDE among useful symbols, and that > might slow down your development process. > > In practice, if you make just few symbols, it just doesn't matter. > If you make lots of them -- say, hundred -- it sort of matters already. > > E.g. if you use a keyword symbol for package name, that's ok -- because > usually you don't have lots of packages, and also you might want > completion to work on package names. > > But if you use keyword symbols for exports and imports in defpackage, > declaration, that might introduce potentially a lot of unwanted symbols. I find it very hard to imagine that this could seriously be a potential bottleneck. Especially, if your project is really that big that this could matter, you're probably already using some other libraries that may or may not worry about using interned symbols in export lists or not, so it hardly matters what you do in your own import/export lists. Apart from that, the memory that is used up by the definitions behind those symbols is probably much larger. Did anyone ever experience serious problems in this regard? 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/
From: Michael Weber on 7 Apr 2010 06:10 On Apr 6, 11:31 am, Tamas K Papp <tkp...(a)gmail.com> wrote: > Hi, > > I am not completely clear on the applications of the #: read macro for > uninterned symbols. Redshank inserts it everywhere before symbols > (defsystem, in-package, and other forms) It's configurable, M-x customize-variable redshank-canonical-package- designator-function RET M/
From: Pillsy on 7 Apr 2010 10:45 On Apr 7, 5:42 am, Pascal Costanza <p...(a)p-cos.net> wrote: > On 06/04/2010 16:51, Captain Obvious wrote: [...] > > E.g. if you use a keyword symbol for package name, that's ok -- because > > usually you don't have lots of packages, and also you might want > > completion to work on package names. > > But if you use keyword symbols for exports and imports in defpackage, > > declaration, that might introduce potentially a lot of unwanted symbols.. > I find it very hard to imagine that this could seriously be a potential > bottleneck. Especially, if your project is really that big that this > could matter, you're probably already using some other libraries that > may or may not worry about using interned symbols in export lists or > not, so it hardly matters what you do in your own import/export lists. I've found that having a bunch of extra crud in the KEYWORD package is a pain because it makes tab completion less useful. If I have a function with a keyword argument :FROBULATOR then also having keywords like :FROBULATORP and :FROBULATOR->GIZMO slows me down for no good reason. It's a petty annoyance, sure, but since the solution is so easy, why not avail myself of it? Cheers, Pillsy
From: Thomas A. Russ on 7 Apr 2010 12:04 Ron Garret <rNOSPAMon(a)flownet.com> writes: > If you find yourself thinking that #:FOO is more appropriate than > (MAKE-SYMBOL "FOO") or #.(MAKE-SYMVBOL "FOO") you are almost certainly > doing something wrong. Well, the place where it makes a difference is when you want to have the reader case conversion effects applied. Otherwise you could instead just use strings for some of the applications (like package exports). I think it is just a way of trying to make libraries a bit more robust when dealing with things like Allegro CL's "modern mode" lisp. Of course, you could use keywords as well, but some programmers don't like the idea of adding additional symbols to the keyword package when all they really care about is, effectively getting (symbol-name '#:foo) Unfortunately, there isn't any nice standard functional interface that gives you the effect of the reader settings when passed a string. -- Thomas A. Russ, USC/Information Sciences Institute
From: RG on 7 Apr 2010 15:18
In article <ymifx37jlk7.fsf(a)blackcat.isi.edu>, tar(a)sevak.isi.edu (Thomas A. Russ) wrote: > Ron Garret <rNOSPAMon(a)flownet.com> writes: > > > If you find yourself thinking that #:FOO is more appropriate than > > (MAKE-SYMBOL "FOO") or #.(MAKE-SYMVBOL "FOO") you are almost certainly > > doing something wrong. > > Well, the place where it makes a difference is when you want to have the > reader case conversion effects applied. Otherwise you could instead > just use strings for some of the applications (like package exports). I > think it is just a way of trying to make libraries a bit more robust > when dealing with things like Allegro CL's "modern mode" lisp. > > Of course, you could use keywords as well, but some programmers don't > like the idea of adding additional symbols to the keyword package when > all they really care about is, effectively getting > > (symbol-name '#:foo) > > Unfortunately, there isn't any nice standard functional interface that > gives you the effect of the reader settings when passed a string. Very well, I concede the point: #: syntax is OK in DEFPACKAGE forms. But anywhere else it's probably a mistake. rg |