Problem with LUCID Common Lisp

[Barry Shein]

murthy at cs.cornell.edu (Chet Murthy):
>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.

Correct, easy enough to verify yourself using (DO-SYMBOLS), pp 187 of
CLTL.

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

If by "foo" you mean foo and not the string "foo" then yes, if you mean
after the first foo was uninterned. If the old foo is still interned then
of course it's re-used (ie. is EQ.)

>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?

If there are no references to the old "foo" it should be reclaimed, there
may be some caveats about this, you might call Lucid. Then again, perhaps
I'm being confused by your use of the term "string", do you really mean
print-name or atom? It makes a hell of a big difference when asking these
questions. Strings can have slightly different rules than atoms in regards
to storage reclamation.

>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?

Yes, but most likely just put aside for re-use (ie. the memory will
probably not be returned to Unix via a negative brk(), just put into a
free atom pool for later re-use.) Does that make a difference?

>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.

Here we agree, but there's also some sort of problem understanding exactly
what you're trying to optimize and the real problem being solved. Not sure
what "major bottlenecks" really means (it runs slowly? it doesn't run at
all or crashes? it just seems wrong?)

Also, compiling the code might cause different behavior than interpreting
it as far as storage management of atoms is concerned, you might have to
do some black-box experiments or ask someone at Lucid.

	-Barry Shein, Software Tool & Die

There's nothing more terrifying to hardware vendors than
satisfied customers.