Problem with LUCID Common Lisp

Chet Murthy murthy at cs.cornell.edu
Sun May 7 01:38:21 AEST 1989


I have an application that uses atoms as strings.  That is, where another
program would have used strings, this one uses atoms.  It usually works OK
because there isn't much string-manipulation going on.  However, I just
started doing major string manipulation, and I started running into major
bottlenecks in intern-ing atoms.  What happens is that every time I want
to construct a string, say to print out, I have to build this atom, which
has to be intern-ed, which means more stuff in the obarray (or whatever
the per-package datastructure that contains stuff like that is called).

Anyway, what I'd like to find out is what exactly happens inside Lucid
common lisp when I execute the following code:

(in-package 'user)
(setq x 'foo)
(unintern x)


I assume that when the parser reads "foo", it interns "foo" into the
current Package.  "unintern" then removes that symbol from the package.

Is it the case that the next time "foo" is read, a completely different
symbol is allocated?

is it the case that the old storage for the string "foo" will be reclaimed
when "x" is set to a different value, after some garbage collection?

I guess what I want to know is: If I intern a bunch of atoms, and then
unintern, and drop all pointers to the atoms, will the storage used by
those atoms ever be reclaimed?

Look, I realize that this is just silly, and I should be doing this
right, with strings instead of atoms, but I don't have that option, so
I'm trying to work-around.

Thanks in advance,

--chet--
-- 
	--chet--
	murthy at svax.cs.cornell.edu
	--chet--
	murthy at svax.cs.cornell.edu



More information about the Comp.sys.sun mailing list