After I changed the microcode to hold only weak references to interned
symbols without global bindings, I noticed a number of problems with
weak hash tables keyed by symbols. The procedure MAKE-EQ-HASH-TABLE,
counterintuitively to me, yields hash tables with only weak references
to their keys. Ma
> Comments?
I agree with your recommendation.
On a related note, in a recent build, I noticed some of my code
failing sporadically to find certain values in EQ hash tables.
Depending on the order in which the code was loaded, one particular
symbol value would be missing from one such table, which
Date: Sat, 19 Dec 2009 23:04:29 -0800
From: "Arthur A. Gleckler"
On a related note, in a recent build, I noticed some of my code
failing sporadically to find certain values in EQ hash tables.
Depending on the order in which the code was loaded, one particular
symbol value would
On Sat, Dec 19, 2009 at 9:50 PM, Taylor R Campbell wrote:
> After I changed the microcode to hold only weak references to interned
> symbols without global bindings, I noticed a number of problems with
> weak hash tables keyed by symbols. The procedure MAKE-EQ-HASH-TABLE,
> counterintuitively to
On Sat, Dec 19, 2009 at 11:04 PM, Arthur A. Gleckler
wrote:
>
> On a related note, in a recent build, I noticed some of my code
> failing sporadically to find certain values in EQ hash tables.
> Depending on the order in which the code was loaded, one particular
> symbol value would be missing fr
Date: Sun, 20 Dec 2009 00:07:17 -0800
From: Joe Marshall
Ignoring the issue of weak symbols for the moment, there is no need
to have strong references to the keys *unless* someone is depending
upon walking the hash table to find them. (and they shouldn't)
I don't buy `they should
On Sun, Dec 20, 2009 at 12:25 AM, Taylor R Campbell wrote:
> Date: Sun, 20 Dec 2009 00:07:17 -0800
> From: Joe Marshall
>
> Ignoring the issue of weak symbols for the moment, there is no need
> to have strong references to the keys *unless* someone is depending
> upon walking the hash t
Date: Sun, 20 Dec 2009 00:43:25 -0800
From: Joe Marshall
On Sun, Dec 20, 2009 at 12:25 AM, Taylor R Campbell
wrote:
> I don't buy `they shouldn't' unless we're prepared to eliminate
> HASH-TABLE/KEY-LIST, HASH-TABLE/DATUM-LIST, HASH-TABLE/FOR-EACH, &c.,
> and then rewrite ever
On Sun, Dec 20, 2009 at 12:59 AM, Taylor R Campbell wrote:
>
> The only reason that this may not have bitten anyone before is that
> nobody has implemented any weak internment scheme for objects that are
> ever used as keys in eq hash tables -- and the other cases are highly
> unlikely to be encou
Date: Sun, 20 Dec 2009 07:55:07 -0800
From: Joe Marshall
It seems to me that a weak internment scheme should not be
observably different from a strong one in any way. It should only
be (potentially) more memory efficient. This implies that if
weakly interned objects are used a
On Sun, Dec 20, 2009 at 8:46 AM, Taylor R Campbell wrote:
> What I observed in MIT Scheme is that, of
> the sixty-two uses of MAKE-EQ-HASH-TABLE, more of them are incorrect,
> and need key-strong hash tables, than actally need key-weak hash
> tables.
This is what I disagree with. If they were c
Date: Sun, 20 Dec 2009 13:48:59 -0800
From: Joe Marshall
On Sun, Dec 20, 2009 at 8:46 AM, Taylor R Campbell
wrote:
> Â What I observed in MIT Scheme is that, of
> the sixty-two uses of MAKE-EQ-HASH-TABLE, more of them are incorrect,
> and need key-strong hash tables, than acta
Now that Joe has "fixed" the handling of interned symbols, we should
address the more general problem that Taylor is concerned with.
The documentation clearly states that make-eq-hash-table returns a
weak table, and has so stated for a long time. So it's not reasonable
to change the semantics ove
> OK?
That's an excellent plan.
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
Date: Sun, 20 Dec 2009 15:21:20 -0800
From: Chris Hanson
The documentation clearly states that make-eq-hash-table returns a
weak table, and has so stated for a long time. So it's not reasonable
to change the semantics overnight. Here's what I propose:
[...]
OK?
Sounds go
Date: Mon, 21 Dec 2009 00:37:10 +
From: eval.ap...@gmail.com
Of course the response to this is that the obarray isn't intended
to be used in this manner. It is not guaranteed to retain symbols
and that it was simply an implementation detail that it happened to
retain them. An
I agree with most of your analysis. Here are my comments:
*** edwin/eystep.scm, ynode-regions
What are the keys to these hash tables? I don't know how long they
persist.
The keys are stepper nodes; they are stored in a text property and
consequently will be held appropriately.
Date: Sun, 20 Dec 2009 21:49:38 -0800
From: Chris Hanson
I agree with most of your analysis.
OK, I'll start making the changes.
*** xml/xml-names.scm
This is hairy: part of it looks like it needs to be datum-weak, but we
don't have that now. But someone more familiar with th
Actually, they want to be both key-weak and datum-weak.
On Mon, Dec 21, 2009 at 9:12 AM, Taylor R Campbell wrote:
> Date: Sun, 20 Dec 2009 21:49:38 -0800
> From: Chris Hanson
>
> I agree with most of your analysis.
>
> OK, I'll start making the changes.
>
> *** xml/xml-names.scm
>
> Th
Date: Mon, 21 Dec 2009 14:03:50 -0800
From: Chris Hanson
Actually, they want to be both key-weak and datum-weak.
EXPANDED-NAMES needs to be key-weak and datum-strong (its data are
hash tables that are not likely to be referenced, strongly or weakly,
from anywhere else), but for the othe
On Dec 20, 2009 2:54pm, Taylor R Campbell wrote:
It is very surprising for hash tables to be weak by
default: that causes parts of data structures to apparently randomly
vanish.
I could argue that it is very surprising for *symbols* to be weak
by default. It causes parts of data structures (i
21 matches
Mail list logo
