"Geo Carncross" geocar@gmail.com writes:
I've been looking over adding weak hashtable support to ECL, when I took a closer look at slime's use of them.
Weak hashtables are a useful feature, so if you want to add them to ECL, I would think this would be a good idea.
They are not an essential feature for SLIME, though.
We started using them in SLIME for presentations in implementations that have weak hashtables, because people complained that all the objects associated with presentations are protected from GC, which can be confusing.
AFAIK, they are not used for anything else in SLIME.
as long as they're in the REPL shouldn't the presentation keep an extra reference to them?
This is an alternative model of using presentations, which could be a useful user option in my opinion.
It has not frequently happened to me, though, that objects that I wanted to access were already garbage collected.
Perhaps a better way to deal with this is to have slime indicate what objects its holding and/or clear this buffer when it stops using them. This might better belong in a per-connection thing, and I wanted some advise on this before I started hacking on this.
In current SLIME, presentations can be cut and pasted arbitrarily, so checking which presentations are "alive" from the Emacs side can be complicated.
A possible way would be using weak hashtables on the Emacs side. Then frequently this hashtable could be scanned, and dead references removed from the Lisp-side strong hashtable.
Code that accomplishes this would be a welcome addition, which I would be happy to merge into the SLIME presentations contrib.
As I said above, this would be an alternative model. We should support both models of operation, and the user should be able to pick one as a user option.
Matthias