Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!husc6!rice!sun-spots-request
From: murthy@cs.cornell.edu (Chet Murthy)
Newsgroups: comp.sys.sun
Subject: Problem with LUCID Common Lisp
Keywords: Software
Message-ID: <27183@cornell.UUCP>
Date: 6 May 89 15:38:21 GMT
Sender: usenet@rice.edu
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 42
Approved: Sun-Spots@rice.edu

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@svax.cs.cornell.edu
	--chet--
	murthy@svax.cs.cornell.edu