This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Dybvig's Guardians etc.


mike@olan.com (Michael N. Livshin) writes:

> Well, a patch that implements Kent Dybvig's Guardians is attached.

Great!

> Meanwhile, some questions:
> 
> 1. Why does Guile have 3 types of weak hash tables (weak-key,
> weak-value, doubly-weak)?  What are they all useful for?

One sign that they aren't trivially unnecessary is that it isn't
possible to implement one of them in terms of the others with the time
complexities of access and mutation intact.

Here's one example (a little bit strained perhaps, but one of the
examples is actually used in Guile):

Assume that you're implementing a debugging system where you want to
associate information about filename and position of source code
expressions with the expressions themselves.

Hashtables can be used for that, but if you use ordinary hash tables
it will be impossible for the scheme interpreter to "forget" old
source when, for example, a file is reloaded.

To implement the mapping from source code expressions to positional
information it is necessary to use weak-key tables since we don't want
the expressions to be remembered just because they are in our table.

To implement a mapping from source file line numbers to source code
expressions you would use a weak-value table.

To implement a mapping from source code expressions to the procedures
they constitute a doubly-weak table has to be used.

The need of weak hash tables typically occur in code that deals with
supervision, maintenance or extension of the interpreter itself, but,
for me, the need has occurred in some other situations as well.

/mdj