Hi,
I use gensyms for macros (like, I believe, many more do). As I
understand it, each time a symbol is read it is interned in the
current package. Well, this means that whenever a macro is executed,
new symbols are interned. When are they garbage collected? Do we have
memory leak due to gensym?
Thanks,
iu2
On Sep 3, 11:31 am, iu2 <·······@elbit.co.il> wrote:
> Hi,
>
> I use gensyms for macros (like, I believe, many more do). As I
> understand it, each time a symbol is read it is interned in the
> current package. Well, this means that whenever a macro is executed,
> new symbols are interned. When are they garbage collected? Do we have
> memory leak due to gensym?
A symbol is never "read". The reader may create a symbol as the
result of reading some characters from a stream, and it may also
intern that symbol in a package (possibly the current one).
GENSYM creates a symbol from whole cloth, and does not intern it in
any package. So no package has a reference to the symbol which will
keep it in being (unless you later intern it yourself). There may be
other references, of course, and the implementation may or may not
actually GC symbols.
Tim Bradshaw <··········@tfeb.org> writes:
> On Sep 3, 11:31 am, iu2 <·······@elbit.co.il> wrote:
>> Hi,
>>
>> I use gensyms for macros (like, I believe, many more do). As I
>> understand it, each time a symbol is read it is interned in the
>> current package. Well, this means that whenever a macro is executed,
>> new symbols are interned. When are they garbage collected? Do we have
>> memory leak due to gensym?
>
> A symbol is never "read". The reader may create a symbol as the
> result of reading some characters from a stream, and it may also
> intern that symbol in a package (possibly the current one).
>
> GENSYM creates a symbol from whole cloth, and does not intern it in
> any package. So no package has a reference to the symbol which will
> keep it in being (unless you later intern it yourself). There may be
> other references, of course, and the implementation may or may not
> actually GC symbols.
You cannot "intern" a symbol, you can only INTERN a symbol name, that
is a string.
But you can "import" a symbol:
C/USER[7]> (import (print (gensym)))
#:G3777
T
C/USER[8]> (find-symbol "G3777")
G3777 ;
:INTERNAL
C/USER[9]>
--
__Pascal Bourguignon__ http://www.informatimago.com/
COMPONENT EQUIVALENCY NOTICE: The subatomic particles (electrons,
protons, etc.) comprising this product are exactly the same in every
measurable respect as those used in the products of other
manufacturers, and no claim to the contrary may legitimately be
expressed or implied.
On Sep 3, 1:51 pm, Pascal Bourguignon <····@informatimago.com> wrote:
> You cannot "intern" a symbol, you can only INTERN a symbol name, that
> is a string.
I think that what the function IMPORT does to a symbol which has no
home package is often considered to be interning it (certainly it is
by me). I agree that the CL function INTERN does not do this. I was,
of course, using the word intern in the former sense (that's why I
said "intern" not "INTERN".
--tim
From: Kent M Pitman
Subject: Re: Symbols - when are they garbage collected?
Date:
Message-ID: <ups0z7a8w.fsf@nhplace.com>
Tim Bradshaw <··········@tfeb.org> writes:
> On Sep 3, 1:51 pm, Pascal Bourguignon <····@informatimago.com> wrote:
>
> > You cannot "intern" a symbol, you can only INTERN a symbol name, that
> > is a string.
>
> I think that what the function IMPORT does to a symbol which has no
> home package is often considered to be interning it (certainly it is
> by me). I agree that the CL function INTERN does not do this. I was,
> of course, using the word intern in the former sense (that's why I
> said "intern" not "INTERN".
I agree with Tim. INTERN, the function, certainly doesn't take symbols as
arguments, but functions often are more idiosyncratic than their Webster's
English counterparts. OPEN, the function, is an operation that takes a
string (or pathname) as its primary input, and yet it's commonly informally
referred to as a file operation, not a string or pathname operation. Again
for the same reason.
But also, from the CLHS glossary:
intern v.t. 1. (a string in a package) to look up the string in the
package, returning either a symbol with that name which was already
accessible in the package or a newly created internal symbol of the
package with that name. 2. Idiom. generally, to observe a protocol
whereby objects which are equivalent or have equivalent names under
some predicate defined by the protocol are mapped to a single
canonical object.
I wrote things like this (and probably this text in specific, though
who can remember for sure) because there are other protocols that are
said to do "interning" besides what one does even just with symbols.
Some people refer to "interned pathnames" on those implementations in
which MAKE-PATHNAME on string= arguments (or sometimes even
string-equal arguments) return the same [under eq] pathname. The
Symbolics LMFS file system did this, for example, and I doubt it's the
only one.
MACLISP, an earlier dialect, interned small fixnums (the
first few hundred--a somewhat randomly chosen number, curiously, using
up some otherwise accidentally unused data space, so not a fixed
amount, and definitely not the whole fixnum range), mostly for space
efficiency [to use the space usefully and to avoid many pointers to
commonly used numbers in a 256KW fixed address space]. Sometimes
this was called EQ-ification ("Eek-if-uh-CAY-shun"), since it made
such small fixnums EQ.
Part of the reason the glossary exists is not just to modularize the
terminology of the language, but also to normalize the vocabulary
among Lisp practitioners. I had felt that there was a rich set of
terms often used by Lispers in places that were "well connected" with
the Lisp implementors and that didn't come up directly in Lisp books,
and so never got farther out and got recreated (sometimes badly) in
obscure places. It was my goal in creating the glossary to just give
people a sense for how the spoken language surrounding the use of Lisp
was done, and that's why I included entries like definition 2
above--to say "if you hear this use of this word, you shouldn't assume
that it's always someone formally trying to wedge the meaning into the
one use that motivated the choice of term as a function name; rather,
the choice of the function name was done by observing that a specific
functional need was filled by this very general concept". No one
would ever assume that if we used "open" to open a file that it was no
longer available to open doors or windows or databases or
conversations or network connections or bank accounts, because the
word is widely used. But for words used less widely, but still with
broader connotation, they needed some additional protection.
- - - -
More Trivia: In MACLISP, which had no packages, symbols that weren't
pointed to could theoretically be GC'd, since they would be recreated
the first time they were later touched, and there was a question about
whether this was worth doing. It usually wasn't done, just to avoid
thrashing and to avoid thinking you had preallocated enough storage
for an application to be able to read data, only to find out you
hadn't. But you could called GCTWA (Garbage Collect Truly Worthless
Atoms) to tell the GC it was ok to collect such symbols.
iu2 <·······@elbit.co.il> writes:
> Hi,
>
> I use gensyms for macros (like, I believe, many more do). As I
> understand it, each time a symbol is read it is interned in the
> current package. Well, this means that whenever a macro is executed,
> new symbols are interned. When are they garbage collected? Do we have
> memory leak due to gensym?
AFAIK symbols generated by gensym are not interned, they are written
with #: before them. Eg
CL-USER> (gensym)
#:G1906
HTH,
Tamas
In article <························@50g2000hsm.googlegroups.com>,
iu2 <·······@elbit.co.il> wrote:
> Hi,
>
> I use gensyms for macros (like, I believe, many more do). As I
> understand it, each time a symbol is read it is interned in the
> current package. Well, this means that whenever a macro is executed,
> new symbols are interned.
Macros are not read when executed.
It means, whenever that macro is expanded, new symbols
are created (but not interned in a package).
Also, gensym creates a symbol which is not interned in a package.
CL-USER> (gensym)
#:G1
CL-USER> (describe *)
Symbol: #:G1
No home package.
Print name: "G1"
Value: #<Unbound>
Function: #<Unbound>
Plist: NIL
; No value
CL-USER> (symbol-package **)
NIL
Additionally, reading such a symbol will not intern it.
CL-USER> (read)
#:foo
#:FOO
CL-USER> (symbol-package *)
NIL
> When are they garbage collected? Do we have
> memory leak due to gensym?
>
> Thanks,
> iu2
--
http://lispm.dyndns.org